From dsummersl at yahoo.com Fri Oct 1 15:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri Oct 1 15:22:55 2004 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl@yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj@www.linux.org.uk > From philip at gladstonefamily.net Wed Oct 6 02:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed Oct 6 01:59:42 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime.bin From daniel at readytechnology.co.uk Wed Oct 6 02:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed Oct 6 02:32:22 2004 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Wed Oct 6 02:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed Oct 6 02:53:50 2004 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22@yahoo.com.ar Jabber ID: fernandezm22@jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20041005/c221170c/attachment.pgp From taj at www.linux.org.uk Wed Oct 6 04:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Oct 6 04:02:35 2004 Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Wed Oct 6 04:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Oct 6 04:10:43 2004 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj@www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 07:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed Oct 6 07:28:59 2004 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22@yahoo.com.ar Jabber ID: fernandezm22@jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0001.pgp From taj at www.linux.org.uk Wed Oct 6 08:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Oct 6 08:15:24 2004 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj@www.linux.org.uk From philip at gladstonefamily.net Thu Oct 7 03:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Thu Oct 7 03:26:56 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20041006/113b5978/smime.bin From taj at www.linux.org.uk Thu Oct 7 03:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu Oct 7 03:46:07 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Thu Oct 7 04:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu Oct 7 03:59:47 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Thu Oct 7 04:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu Oct 7 04:21:33 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Thu Oct 7 07:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu Oct 7 07:32:37 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 16:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri Oct 8 16:46:43 2004 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Sat Oct 9 01:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat Oct 9 01:00:06 2004 Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj@www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 09:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat Oct 9 09:05:32 2004 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex@corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 09:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat Oct 9 09:30:31 2004 Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex@corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 16:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Oct 11 16:35:21 2004 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 17:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Oct 11 17:01:32 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj@www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 17:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon Oct 11 17:13:49 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime.bin From taj at www.linux.org.uk Mon Oct 11 18:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Oct 11 18:05:25 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj@www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 22:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon Oct 11 22:31:36 2004 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 23:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon Oct 11 23:13:53 2004 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org > [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 10:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Oct 12 10:56:18 2004 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj@www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 19:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue Oct 12 19:13:38 2004 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 17:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Oct 13 17:12:12 2004 Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 17:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat Oct 16 17:27:32 2004 Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 20:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue Oct 19 20:44:58 2004 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 20:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu Oct 21 20:02:09 2004 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 23:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Thu Oct 21 23:15:39 2004 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 08:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Oct 22 08:34:03 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 17:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat Oct 23 17:47:03 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 18:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat Oct 23 18:17:38 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 22:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat Oct 23 22:14:38 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 22:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat Oct 23 22:39:24 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 15:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun Oct 24 15:26:15 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 15:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun Oct 24 15:55:08 2004 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj@www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 23:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun Oct 24 23:00:47 2004 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 23:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun Oct 24 23:26:27 2004 Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj@www.linux.org.uk From dessarps at bktel.com Sun Oct 31 09:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun Oct 31 09:54:42 2004 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root@bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root@bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 15:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun Oct 31 15:29:17 2004 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 15:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl@yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj@www.linux.org.uk > From philip at gladstonefamily.net Wed Oct 6 02:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime-0002.bin From daniel at readytechnology.co.uk Wed Oct 6 02:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Wed Oct 6 02:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22@yahoo.com.ar Jabber ID: fernandezm22@jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041005/c221170c/attachment-0002.pgp From taj at www.linux.org.uk Wed Oct 6 04:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Wed Oct 6 04:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj@www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 07:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22@yahoo.com.ar Jabber ID: fernandezm22@jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0002.pgp From taj at www.linux.org.uk Wed Oct 6 08:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj@www.linux.org.uk From philip at gladstonefamily.net Thu Oct 7 03:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Fri Jun 3 17:46:46 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041006/113b5978/smime-0002.bin From taj at www.linux.org.uk Thu Oct 7 03:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Thu Oct 7 04:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Thu Oct 7 04:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Thu Oct 7 07:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 16:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Sat Oct 9 01:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj@www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 09:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex@corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 09:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex@corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 16:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 17:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj@www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 17:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Fri Jun 3 17:46:47 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0002.bin From taj at www.linux.org.uk Mon Oct 11 18:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj@www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 22:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 23:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org > [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 10:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj@www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 19:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 17:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 17:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 20:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 20:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 23:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 08:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 17:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 18:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 22:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 17:46:48 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 22:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 15:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 15:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj@www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 23:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 23:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj@www.linux.org.uk From dessarps at bktel.com Sun Oct 31 09:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root@bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root@bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 15:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 17:46:49 2005 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 15:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl@yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj@www.linux.org.uk > From philip at gladstonefamily.net Wed Oct 6 02:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime-0003.bin From daniel at readytechnology.co.uk Wed Oct 6 02:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Wed Oct 6 02:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22@yahoo.com.ar Jabber ID: fernandezm22@jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041005/c221170c/attachment-0003.pgp From taj at www.linux.org.uk Wed Oct 6 04:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Wed Oct 6 04:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj@www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 07:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22@yahoo.com.ar Jabber ID: fernandezm22@jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0003.pgp From taj at www.linux.org.uk Wed Oct 6 08:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj@www.linux.org.uk From philip at gladstonefamily.net Thu Oct 7 03:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041006/113b5978/smime-0003.bin From taj at www.linux.org.uk Thu Oct 7 03:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:09 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Thu Oct 7 04:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Thu Oct 7 04:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Thu Oct 7 07:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 16:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Sat Oct 9 01:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj@www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 09:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex@corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 09:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex@corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 16:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 17:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj@www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 17:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0003.bin From taj at www.linux.org.uk Mon Oct 11 18:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:10 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj@www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 22:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 23:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org > [mailto:rxtx-bounces@linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 10:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj@www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 19:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 17:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 17:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 20:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 20:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 23:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 08:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 17:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 18:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 22:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 18:09:11 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 22:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 15:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 15:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous@cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj@www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx@linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 23:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 23:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj@www.linux.org.uk From dessarps at bktel.com Sun Oct 31 09:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root@bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root@bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 15:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri Jun 3 18:09:12 2005 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0395.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0395.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0395.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0392.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0395.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0395.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0396.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0396.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0396.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0393.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0396.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0396.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0397.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0397.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0397.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0394.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0397.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0397.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0398.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0398.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0398.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0395.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0398.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0398.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0399.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0399.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0399.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0396.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0399.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0399.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0400.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0400.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0400.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0397.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0400.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0400.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0401.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0401.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0401.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0398.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0401.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0401.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0402.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0402.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0402.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0399.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0402.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0402.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0403.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0403.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0403.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0400.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0403.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0403.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0404.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0404.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0404.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0401.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0404.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0404.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0001.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0001.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0001.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0001.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0001.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0002.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0002.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0002.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0002.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0002.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0002.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0003.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0003.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0003.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0003.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0003.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0003.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0004.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0004.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0004.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0004.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0004.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0004.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0005.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0005.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0005.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0005.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0005.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0005.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0006.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0006.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0006.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0006.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0006.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0006.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0007.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0007.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0007.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0007.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0007.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0007.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0008.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0008.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0008.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0008.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0008.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0008.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0009.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0009.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0009.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0009.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0009.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0009.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0010.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0010.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0010.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0010.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0010.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0010.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0001.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0001.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0001.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0001.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0001.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0002.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0002.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0002.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0002.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0002.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0002.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0003.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0003.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0003.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0003.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0003.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0003.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0004.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0004.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0004.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0004.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0004.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0004.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0005.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0005.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0005.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0005.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0005.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0005.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0006.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0006.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0006.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0006.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0006.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0006.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0007.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0007.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0007.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0007.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0007.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0007.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0008.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0008.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0008.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0008.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0008.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0008.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0009.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0009.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0009.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0009.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0009.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0009.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0010.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0010.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0010.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0010.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0010.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0010.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0001.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0001.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0001.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0001.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0001.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0002.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0002.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0002.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0002.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0002.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0002.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0003.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0003.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0003.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0003.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0003.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0003.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0004.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0004.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0004.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0004.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0004.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0004.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0005.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0005.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0005.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0005.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0005.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0005.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0006.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0006.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0006.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0006.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0006.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0006.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0007.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0007.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0007.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0007.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0007.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0007.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/d6d2df74/smime-0008.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/c221170c/attachment-0008.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0008.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/pre17-0008.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041007/113b5978/smime-0008.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0008.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/c221170c/attachment.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0009.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/pre17.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/smime.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0009.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime-0001.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/c221170c/attachment-0001.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0010.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/pre17-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/smime-0001.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0010.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime-0002.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/c221170c/attachment-0002.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0011.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/pre17-0002.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/smime-0002.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0011.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime-0003.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/c221170c/attachment-0003.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0012.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/pre17-0003.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/smime-0003.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # An error report file has been saved as hs_err_pid5884.log. # Please refer to the file for further information. # Abandon I don't get where i am wrong Thanks in advance Alexandre From taj at www.linux.org.uk Sat Oct 9 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 09:33:21 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <41679CAF.8030404@free.fr> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> <41679CAF.8030404@free.fr> Message-ID: On Sat, 9 Oct 2004, alexandre ricciardi wrote: > Hi, > > I have just installed rxtx on jdk 1.4.2_05, > > i get the following error message, that i don't understand : > > > > alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify > JavaKit > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x40009315 > Function=_dl_relocate_object+0x65 > Library=/lib/ld-linux.so.2 > > Current Java thread: > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) > - locked <0x44c8c438> (a java.util.Vector) > - locked <0x44c947f0> (a java.util.Vector) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > - locked <0x44c8b7a8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(System.java:834) > at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) > at > javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) > at > javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > Dynamic libraries: > 08048000-08056000 r-xp 00000000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 08056000-08059000 rw-p 0000d000 03:01 1387607 > /usr/local/java/j2sdk1.4.2_05/bin/java > 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so > 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so > 40018000-40020000 r-xp 00000000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40020000-40021000 rw-p 00007000 03:01 147630 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so > 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 > 40025000-40026000 r--p 004bf000 03:01 603894 > /usr/lib/locale/locale-archive > 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so > 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so > 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so > 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so > 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so > 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so > 401b0000-405ac000 r-xp 00000000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405ac000-405c7000 rw-p 003fb000 03:01 359800 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so > 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so > 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so > 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so > 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so > 40610000-40613000 r--s 00000000 03:01 392294 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar > 40613000-4061b000 r--s 00000000 03:01 392299 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar > 4061b000-4061f000 r-xp 00000000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 4061f000-40620000 rw-p 00004000 03:01 1371144 > /usr/X11R6/lib/libXtst.so.6.1 > 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so > 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so > 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so > 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so > 4063a000-4064a000 r-xp 00000000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064a000-4064c000 rw-p 0000f000 03:01 147637 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so > 4064c000-4066c000 r-xp 00000000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066c000-4066e000 rw-p 0001f000 03:01 147638 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so > 4066e000-40682000 r-xp 00000000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40682000-40685000 rw-p 00013000 03:01 147640 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so > 40685000-42029000 r--s 00000000 03:01 147707 > /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar > 42073000-42089000 r--s 00000000 03:01 147662 > /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar > 42089000-42166000 r--s 00000000 03:01 147704 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar > 42166000-42177000 r--s 00000000 03:01 147663 > /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar > 42177000-426d0000 r--s 00000000 03:01 147705 > /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar > 44778000-4477f000 r--s 00000000 03:01 392665 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar > 4c800000-4ca00000 r--p 00000000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca00000-4ca34000 r--p 00487000 03:01 603894 > /usr/lib/locale/locale-archive > 4ca34000-4ca50000 r--s 00000000 03:01 391832 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar > 4ca50000-4ca5d000 r--s 00000000 03:01 392574 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar > 4ca5d000-4cb19000 r--s 00000000 03:01 392664 > /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar > 4cb19000-4cb3d000 r--s 00000000 03:01 17389 > /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar > 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so > 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so > 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 > /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 > 4cea0000-4cea8000 r-xp 00000000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea8000-4cea9000 rw-p 00007000 03:01 49180 > /usr/lib/libXcursor.so.1.0.2 > 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 > /usr/lib/gconv/ISO8859-15.so > 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 > 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 > 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 > /usr/X11R6/lib/libXext.so.6.4 > 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 > /usr/X11R6/lib/libX11.so.6.2 > 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 > 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 > /usr/X11R6/lib/libICE.so.6.3 > 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so > 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 > /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so > 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 > /usr/lib/libXrender.so.1.2.2 > 4d0e9000-4d105000 r-xp 00000000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > 4d105000-4d107000 rw-p 0001b000 03:01 783425 > /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 > > Heap at VM Abort: > Heap > def new generation total 576K, used 499K [0x44780000, 0x44820000, > 0x44c60000) > eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) > from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) > to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) > tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, > 0x48780000) > the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, > 0x44dc0000) > compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, > 0x4c780000) > the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, > 0x48bc0000) > > Local Time = Sat Oct 9 10:03:56 2004 > Elapsed Time = 0 > # > # The exception above was detected in native code outside the VM > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # An error report file has been saved as hs_err_pid5884.log. > # Please refer to the file for further information. > # > Abandon > > I don't get where i am wrong > > Thanks in advance > > Alexandre We do have 2 bugs I hope to get fixes out for this weekend but this looks different. The problem looks strange. I suspect this is an ABI problem and recompiling the library will result in one that loads. You can also play around with LD_ASSUME_KERNEL but I suspect recompiling is going to be the easiest. http://people.redhat.com/drepper/assumekernel.html You may run into another SIG11 which I think we have identified. But that happens somewhat randomly not at library loading. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 09:35:44 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 16:35:44 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: A preview of rxtx-2.1-7pre18 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni BlackBox is not showing any problems with JNIEnv being passed between threads (but some ports use a different code path). The code Dmitry mentioned was added and converted from C++ to C as needed but I'm not seeing anyplace its needed at this time. We had moved some of the problematic code into Java avoiding the problem as far as I can tell. The main thing I think that will help stability is a stack overflow was found due to erroneous inclusion of termbits.h. Configure support for 1.5 was added and thats what I'm testing with. I've probably missed some credits but here is what we have in Changelog: 2.1-7pre18 release locks when device is unavailable. Tico Ballagas J2SE java.util.loggin and property file to match Stephane Cachat termios stack overflow fix for Linux caused by including termbits.h Bill Holmes Support for USB frobs in Linux (reports are that this does not work exactly as expected with some kernels) Christopher R. Wren configure fix for jdk 1.5 Please give it a try if you have time. If you see something missing or experience problems, dont be afraid to drop an email. I'll be testing too. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Mon Oct 11 10:02:00 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 17:02:00 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > > Philip > > This patch may still make sense. I thought the -Xcheck:jni would expose problems but its not showing up. I'll get my ibutton and test here too. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Mon Oct 11 10:14:08 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Mon, 11 Oct 2004 12:14:08 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <416AB150.1070401@gladstonefamily.net> Do you want me to try -Xcheck:jni with the old code to see if it reports an error? I could probably do this tonight. Philip Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > >>Philip Gladstone wrote: >> >> >>>Hi, >>> >>>I get a reproducible crash in my jvm running on linux. The stack >>>backtrace shows: >>> >> >>After a bit more poking around, I think that I found my problem. It >>turns out that the nativeDrain function was calling send_event which >>then used the JNIEnv pointer from the wrong thread. This is (apparently) >>a big nono. >> >>The attached patch fixes that problem, and also fixes a problem on SuSE >>linux (the lock directories are not all distinct -- some are symlinked >>to each other. This causes problems if there are surplus lock files). >> >>After applying this patch, my system has been running for a couple of >>hours, where it used to crash within minutes. >> >>Philip >> >> > > > This patch may still make sense. I thought the -Xcheck:jni would expose > problems but its not showing up. > > I'll get my ibutton and test here too. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041011/e9e2a8b2/smime-0012.bin From taj at www.linux.org.uk Mon Oct 11 11:05:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 11 Oct 2004 18:05:50 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416AB150.1070401@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <416AB150.1070401@gladstonefamily.net> Message-ID: On Mon, 11 Oct 2004, Philip Gladstone wrote: > Do you want me to try -Xcheck:jni with the old code to see if it reports > an error? I could probably do this tonight. > > Philip I had only looked back at the issue in the mail-list archive. In this post http://marc.theaimsgroup.com/?l=rxtx&m=107167326803611&w=2 BSD was able to see the problem. At the time we did not have the same options and the JDK was not a public release for BSD. I have a great deal of testing to do and looking at the previous library with the same options should be interesting. Getting rid of the Java variables in the event info struct is the sure way to avoid these problems. Stack corruption with the termbits.h may well be whats causing the problems for most folks on Linux though. > > Trent Jarvi wrote: > > On Wed, 6 Oct 2004, Philip Gladstone wrote: > > > > > >>Philip Gladstone wrote: > >> > >> > >>>Hi, > >>> > >>>I get a reproducible crash in my jvm running on linux. The stack > >>>backtrace shows: > >>> > >> > >>After a bit more poking around, I think that I found my problem. It > >>turns out that the nativeDrain function was calling send_event which > >>then used the JNIEnv pointer from the wrong thread. This is (apparently) > >>a big nono. > >> > >>The attached patch fixes that problem, and also fixes a problem on SuSE > >>linux (the lock directories are not all distinct -- some are symlinked > >>to each other. This causes problems if there are surplus lock files). > >> > >>After applying this patch, my system has been running for a couple of > >>hours, where it used to crash within minutes. > >> > >>Philip > >> > >> > > > > > > This patch may still make sense. I thought the -Xcheck:jni would expose > > problems but its not showing up. > > > > I'll get my ibutton and test here too. > > > -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Mon Oct 11 15:31:45 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 16:31:45 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C477F@misnts1.dalsemi.com> Trent, > A preview of rxtx-2.1-7pre18 is in CVS. ... > Mainly I'm interested in knowing if we have solved sig11 > issues for those that have them. ... I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a crash. The app I'm using does seem to run for a while (just as before), then crashes. Here's the full output: $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 Found adapter: DS9097U on port: /dev/ttyS0 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # # Error ID: 53414645504F494E540E4350500175 # # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable # Heap at VM Abort: Heap def new generation total 576K, used 9K [0xecf70000, 0xed010000, 0xed450000) eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, 0xf0f70000) the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, 0xed794000) compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, 0xf4f70000) the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, 0xf17f0000) Aborted You can get the jars I was using for testing with the iButton directly here: http://www.ibutton.com/software/1wire/OneWireAPI.jar http://www.ibutton.com/software/1wire/OneWireViewer.jar To install rxtx-2.1-7pre18, I followed your instructions to fetch from CVS.. Then, did "configure; make; make install;". $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Scott Hughes - Engineer shughes aht dalsemi daut com From Scott.Hughes at dalsemi.com Mon Oct 11 16:13:56 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 11 Oct 2004 17:13:56 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre18 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C47BA@misnts1.dalsemi.com> Trent, Also, I tried the same app again with "-Xcheck:jni", and I get the following exception on startup: $ java -Xcheck:jni -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.1-7pre18 Java lib Version = RXTX-2.1-7pre18 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 FATAL ERROR in native method: Using JNIEnv in the wrong thread at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1191) at com.dalsemi.onewire.adapter.SerialService.flush(SerialService.java:460) - locked <0xecf70728> (a com.dalsemi.onewire.adapter.SerialService) at com.dalsemi.onewire.adapter.USerialAdapter.uMasterReset(USerialAdapter.java: 2554) at com.dalsemi.onewire.adapter.USerialAdapter.uAdapterPresent(USerialAdapter.ja va:2497) at com.dalsemi.onewire.adapter.USerialAdapter.adapterDetected(USerialAdapter.ja va:458) at com.dalsemi.onewire.OneWireAccessProvider.getAdapter(OneWireAccessProvider.j ava:377) at OneWireViewer.main(Unknown Source) Aborted -- Scott Hughes - Engineer shughes aht dalsemi daut com > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org > [mailto:rxtx-bounces at linuxgrrls.org] On Behalf Of Scott Hughes > Sent: Monday, October 11, 2004 4:32 PM > To: Java RXTX discussion > Subject: RE: [Rxtx] Preview of rxtx-2.1-7pre18 available > > Trent, > > > A preview of rxtx-2.1-7pre18 is in CVS. > ... > > Mainly I'm interested in knowing if we have solved sig11 > > issues for those that have them. > ... > > I tried rxtx-2.1-7pre18 on an FC2 box, and I still get a > crash. The app I'm > using does seem to run for a while (just as before), then > crashes. Here's > the full output: > > > $ java -cp "OneWireAPI.jar:OneWireViewer.jar" OneWireViewer > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre18 > Java lib Version = RXTX-2.1-7pre18 > Found adapter: DS9097U > on port: /dev/ttyS0 > # > # HotSpot Virtual Machine Error, Internal Error > # Please report this error at > # http://java.sun.com/cgi-bin/bugreport.cgi > # > # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) > # > # Error ID: 53414645504F494E540E4350500175 > # > # Problematic Thread: prio=1 tid=0x081b4b88 nid=0x662d runnable > # > > Heap at VM Abort: > Heap > def new generation total 576K, used 9K [0xecf70000, 0xed010000, > 0xed450000) > eden space 512K, 0% used [0xecf70000, 0xecf70000, 0xecff0000) > from space 64K, 14% used [0xecff0000, 0xecff2428, 0xed000000) > to space 64K, 0% used [0xed000000, 0xed000000, 0xed010000) > tenured generation total 3344K, used 2528K [0xed450000, 0xed794000, > 0xf0f70000) > the space 3344K, 75% used [0xed450000, 0xed6c8380, 0xed6c8400, > 0xed794000) > compacting perm gen total 8704K, used 8632K [0xf0f70000, 0xf17f0000, > 0xf4f70000) > the space 8704K, 99% used [0xf0f70000, 0xf17de290, 0xf17de400, > 0xf17f0000) > Aborted > > > You can get the jars I was using for testing with the iButton > directly here: > http://www.ibutton.com/software/1wire/OneWireAPI.jar > http://www.ibutton.com/software/1wire/OneWireViewer.jar > > To install rxtx-2.1-7pre18, I followed your instructions to > fetch from CVS.. > Then, did "configure; make; make install;". > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > -- > Scott Hughes - Engineer > shughes aht dalsemi daut com > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Tue Oct 12 03:56:50 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 12 Oct 2004 10:56:50 +0100 (BST) Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available In-Reply-To: References: Message-ID: OK, lets try this again. Still just hunting down the SIG11s mostly. A preview of rxtx-2.1-7pre19 is in CVS. Its only been lightly tested on Linux at this point. I will provide win32 libraries shortly but I'm just trying to see if people with problems are getting SIG11's. CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (password mousy) cvs checkout -r commapi-0-0-1 rxtx-devel This is the gnu.io version of rxtx that does not require Suns comm.jar So far I've only tested BlackBox modified to use gnu.io with a loopback and the iButton OneWireViewer with a java iButton. Mainly I'm interested in knowing if we have solved sig11 issues for those that have them. The CPU use was 0% going 115200 Baud. java -Xcheck:jni So far no problems with SIG11s have been found with this release. 2.1-7pre19 Oct 12 2004 Thread safer nativeDrain()/flush() method. Philip Gladstone Don't look for unexpected lockfiles in expected places Philip Gladstone adding the new properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts insead of overriding the system properties and uses them only as default values Klaus Kierer Please let me know if you see problems or have something you want to get in. -- Trent Jarvi taj at www.linux.org.uk From Scott.Hughes at dalsemi.com Tue Oct 12 12:14:00 2004 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Tue, 12 Oct 2004 13:14:00 -0500 Subject: [Rxtx] Preview of rxtx-2.1-7pre19 available Message-ID: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Trent, > OK, lets try this again. Still just hunting down the SIG11s mostly. Looks like you fixed the ones I was encountering. OneWireViewer now has been running for about 3 hours continuously (used to crash in less than 5 minutes), with near-constant serial I/O in 2 separate threads. I'm eager to try a w32 binary, as soon as someone has one to share. Scott -- Scott Hughes - Engineer shughes aht dalsemi daut com From taj at www.linux.org.uk Wed Oct 13 10:13:03 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 13 Oct 2004 17:13:03 +0100 (BST) Subject: [Rxtx] Win32 Preview of rxtx-2.1-7pre19 available In-Reply-To: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF2194205C49B5@misnts1.dalsemi.com> Message-ID: On Tue, 12 Oct 2004, Scott Hughes wrote: > Trent, > > > OK, lets try this again. Still just hunting down the SIG11s mostly. > > Looks like you fixed the ones I was encountering. OneWireViewer now has > been running for about 3 hours continuously (used to crash in less than 5 > minutes), with near-constant serial I/O in 2 separate threads. > > I'm eager to try a w32 binary, as soon as someone has one to share. > Here are some test binaries for w32 ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip The binary has been cross compiled from Linux. The jar is in the top directory and the dll's are in the i386-pc-mingw32 subdirectory. Its just a zip of the build directory. Only one tiny change was made to CVS to correct a build error for this. I'm trying to run XPSP1, Sun Java 1.5.0 in VMware on Linux with 256 megs RAM and things are 'a bit goofy.' The HD light has been pegged with swapping for some time. Windows just isnt going very fast in this very constrained environment. Keyboard bounce at 300 Baud has nothing on this setup. But the OneWireViewerr application did load and display the iButton. It isn't crashing but I'd really like more feedback. My system just isnt up for this task. I didnt try BlackBox on w32 yet. The CPU use appears to be around 20% for Java on a 1.5Ghz machine. I'm not ready to trust much of what I see at this point as you might imagine. The final tests will have to run for some time here. Please let me know if you see any problems so I can get right to them. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Sat Oct 16 10:27:49 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 16 Oct 2004 17:27:49 +0100 (BST) Subject: [Rxtx] 2.1-7pre20 in CVS Message-ID: 2.1-7pre20 Oct 16 2004 x86_64 Linux Fixes fixes - BlackBox Serial now runs switch to JNI_VERSION_1_2 -- many people are still using 1.3 JREs Todo: - possible close issue reported (which os?). - possible w32 parallel write issue reported (need to find something to test with). - Big round of testing in about two weeks on i386,x86_64 Linux, Solaris, Windows* with JRE 1.4. Less testing with 1.5 but some. If you have something you want in try to get in in before the end of the month. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Tue Oct 19 13:48:49 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Tue, 19 Oct 2004 21:48:49 +0200 Subject: [Rxtx] Test - Please Excuse. Message-ID: It seems my last message wasn't delivered; Just sending a test message to confirm. Glen. From mikkal56 at hotmail.com Thu Oct 21 13:04:33 2004 From: mikkal56 at hotmail.com (miguel lam) Date: Thu, 21 Oct 2004 19:04:33 +0000 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: Please give the url where I can find the patch, PLEASE !!!!!!!!! _________________________________________________________________ MSN Amor: busca tu ? naranja http://latam.msn.com/amor/ From lonedesign_2k at yahoo.com Thu Oct 21 16:20:08 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Fri, 22 Oct 2004 00:20:08 +0200 Subject: [Rxtx] Question regarding current versions Message-ID: Hi again, Not sure what happened the first time, but anyway, here goes again... I just wanted to start off with a quick question regarding version choice, and later I may (probably will) require some assistance with the actual installation if possible. Question (1): I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is it only a change in API? The one API matching that of Sun, and the other a non-Sun compliant API? Essentially the question is: What version should I be using? And what are the pro's and con's of each? TIA. Glen. From taj at www.linux.org.uk Fri Oct 22 01:37:07 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri, 22 Oct 2004 08:37:07 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 10:52:01 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 18:52:01 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Thanks Trent, And as far as portability is concerned? In the case of v2.0 does it just mean that you have to ensure 2 different things are setup correctly for each installation (RXTX and Commapi), as apposed to one (RXTX) (?) Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux users, or does it only occur under specific conditions? Thanks again, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 22 October 2004 09:37 To: Java RXTX discussion Subject: Re: [Rxtx] Question regarding current versions On Fri, 22 Oct 2004, Dodger wrote: > Hi again, > > Not sure what happened the first time, but anyway, here goes again... > > I just wanted to start off with a quick question regarding version choice, > and later I may (probably will) require some assistance with the actual > installation if possible. > > Question (1): > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. Is > it only a change in API? The one API matching that of Sun, and the other a > non-Sun compliant API? Essentially the question is: What version should I be > using? And what are the pro's and con's of each? > > TIA. > > Glen. > rxtx 2.1 is a full library and does not require any files from Sun. Its package name is different to avoid conflicting with Sun's namespace but otherwise its the same. The same methods and classes are available. rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's namespace. Its all the same code underneath. So The choice is just that. You can use either one. There shouldnt be any advantage of one over the other. When the package is released, the same code is just modified to match the packages. -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 11:21:05 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 18:21:05 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sat Oct 23 15:19:53 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sat, 23 Oct 2004 23:19:53 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Hi Trent, Thanks so much for your assistance so far. I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', as I'm not too clued up on CVS/build files etc., yet. Just copied the native library and the rxtx jar file; I assume that is all that is required for serial comms.? Anyway...It's working; But, I get an error when doing a simple enumeration, the complete output follows: Version: RXTX-2.1-7pre17 RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists /dev/ttyS1 I can post the source if necessary. It just prints the version information and then enumerates the available serial ports. I think that that port may be being used by my modem, and the modem may hold a lock on it. If this is so, is this normal behaviour? Environment: Red Hat 8.0, Java - JDK 1.5.0 Regards, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 19:21 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Thanks Trent, > > And as far as portability is concerned? In the case of v2.0 does it just > mean that you have to ensure 2 different things are setup correctly for each > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all linux > users, or does it only occur under specific conditions? > > Thanks again, > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure this is what was causing problems on BSD and slower w32 machines with earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to bring the changes to 2.0 CVS yet. All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included for those that need it. So all OSs use Suns CommAPI for Solaris (even w32) and a javax.comm.properties file. RXTX 2.1 exposes some methods that are not part of CommAPI and are documented as extensions. These are not recommeneded but are available in 2.1 so its under a completely different namespace. Code can move from javax.comm to gnu.io with just a change in the package name for the most part but code using gnu.io exensions to commapi can not move back to javax.comm without modification (removal of the extensions). What I'd recommend right now is using rxtx 2.1 from CVS with only Sun documented Methods. The package can be changed to javax.comm and comm.jar can be used with rxtx 2.0 later. There are a few people chasing each other with vacations but I expect the code in 2.1 CVS is going to be released as 2.1.7 and 2.0.7 the second week of November after some formal testing. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login (mousy for password) cvs checkout -r commapi-0-0-1 rxtx-devel cd rxtx-devel mkdir build cd build && ../configure && make install w32 bins (minus some 64 bit fixes which are not needed) can be obtained at ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > Glen. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 22 October 2004 09:37 > To: Java RXTX discussion > Subject: Re: [Rxtx] Question regarding current versions > > > On Fri, 22 Oct 2004, Dodger wrote: > > > Hi again, > > > > Not sure what happened the first time, but anyway, here goes again... > > > > I just wanted to start off with a quick question regarding version choice, > > and later I may (probably will) require some assistance with the actual > > installation if possible. > > > > Question (1): > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > Is > > it only a change in API? The one API matching that of Sun, and the other a > > non-Sun compliant API? Essentially the question is: What version should I > be > > using? And what are the pro's and con's of each? > > > > TIA. > > > > Glen. > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > package name is different to avoid conflicting with Sun's namespace but > otherwise its the same. The same methods and classes are available. > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > namespace. > > Its all the same code underneath. So The choice is just that. You can > use either one. There shouldnt be any advantage of one over the other. > When the package is released, the same code is just modified to match the > packages. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sat Oct 23 15:42:52 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 23 Oct 2004 22:42:52 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From lonedesign_2k at yahoo.com Sun Oct 24 08:31:35 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 24 Oct 2004 16:31:35 +0200 Subject: [Rxtx] Question regarding current versions In-Reply-To: Message-ID: Trent, I'm so sorry to bother you again, but I need some help with a windows installation, if possible. I can't seem to find reliable information regarding the placement of the native libraries and rxtx jar file. >From a website: "RXTX is installed by simply copying rxtxSerial.dll into your /bin folder and copying RXTXcomm.jar into your /lib/ext folder." Am I correct in assuming this information is for the application runtime only? I have just installed JDK 1.5.0, and as you may well know, it installs both a public and a private JRE: Public: Java/jre1.5.0 Private: Java/jdk1.5.0/jre Do the files have to go in both locations? Please give me simple directions as to where each of these three files should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). Thanking you in advance, Glen. -----Original Message----- From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On Behalf Of Trent Jarvi Sent: 23 October 2004 23:43 To: Java RXTX discussion Subject: RE: [Rxtx] Question regarding current versions On Sat, 23 Oct 2004, Dodger wrote: > Hi Trent, > > Thanks so much for your assistance so far. > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > as I'm not too clued up on CVS/build files etc., yet. Just copied the native > library and the rxtx jar file; I assume that is all that is required for > serial comms.? > > Anyway...It's working; But, I get an error when doing a simple enumeration, > the complete output follows: > > Version: RXTX-2.1-7pre17 > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File exists > /dev/ttyS1 > > I can post the source if necessary. It just prints the version information > and then enumerates the available serial ports. > > I think that that port may be being used by my modem, and the modem may hold > a lock on it. If this is so, is this normal behaviour? > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > If the program fails to close a port, the file will still be there. If you have a program running in another terminal or in the background, the lock file will be there and for good reason. Inside the lockfile is the PID of the application that left the lockfile. ps up `< /var/lock/LCK..ttyS0` Should show which application has the lock. ps up `< /var/lock/LCK..ttyS0` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java BlackBox -p /de Make sure your user is in group lock /etc/group ... lock:x:54:rm-rf,jarvi,rxtx ... places users rm-rf, jarvi and rxtx in group lock. Full distributions have locking libraries that rxtx could use but these are not available on all systems. Finally, make sure your application closes the port before exiting. If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try taking the modem. It would have killed your internet connection. More often, someone runs an application in one window and then runs it again in another window. The idea is to prevent applications from reading each others data. The messages are printed so people know why enumeration comes up with no available ports when something else has them open. > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 19:21 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Thanks Trent, > > > > And as far as portability is concerned? In the case of v2.0 does it just > > mean that you have to ensure 2 different things are setup correctly for > each > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > linux > > users, or does it only occur under specific conditions? > > > > Thanks again, > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > this is what was causing problems on BSD and slower w32 machines with > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > bring the changes to 2.0 CVS yet. > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > for those that need it. So all OSs use Suns CommAPI for Solaris (even > w32) and a javax.comm.properties file. > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > documented as extensions. These are not recommeneded but are available in > 2.1 so its under a completely different namespace. Code can move from > javax.comm to gnu.io with just a change in the package name for the most > part but code using gnu.io exensions to commapi can not move back to > javax.comm without modification (removal of the extensions). > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > documented Methods. The package can be changed to javax.comm and comm.jar > can be used with rxtx 2.0 later. There are a few people chasing each > other with vacations but I expect the code in 2.1 CVS is going to be > released as 2.1.7 and 2.0.7 the second week of November after some formal > testing. > > export > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > cvs login (mousy for password) > cvs checkout -r commapi-0-0-1 rxtx-devel > cd rxtx-devel > mkdir build > cd build && ../configure && make install > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > Glen. > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 22 October 2004 09:37 > > To: Java RXTX discussion > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > Hi again, > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > I just wanted to start off with a quick question regarding version > choice, > > > and later I may (probably will) require some assistance with the actual > > > installation if possible. > > > > > > Question (1): > > > > > > I'm not sure I understand the difference/s between versions 2.0 and 2.1. > > Is > > > it only a change in API? The one API matching that of Sun, and the other > a > > > non-Sun compliant API? Essentially the question is: What version should > I > > be > > > using? And what are the pro's and con's of each? > > > > > > TIA. > > > > > > Glen. > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > package name is different to avoid conflicting with Sun's namespace but > > otherwise its the same. The same methods and classes are available. > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under Sun's > > namespace. > > > > Its all the same code underneath. So The choice is just that. You can > > use either one. There shouldnt be any advantage of one over the other. > > When the package is released, the same code is just modified to match the > > packages. > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From taj at www.linux.org.uk Sun Oct 24 08:58:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 15:58:48 +0100 (BST) Subject: [Rxtx] Question regarding current versions In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Dodger wrote: > Trent, > > I'm so sorry to bother you again, but I need some help with a windows > installation, if possible. > > I can't seem to find reliable information regarding the placement of the > native libraries and rxtx jar file. > > >From a website: "RXTX is installed by simply copying rxtxSerial.dll into > your /bin folder and copying RXTXcomm.jar into your /lib/ext > folder." > > Am I correct in assuming this information is for the application runtime > only? > > I have just installed JDK 1.5.0, and as you may well know, it installs both > a public and a private JRE: > > Public: Java/jre1.5.0 > Private: Java/jdk1.5.0/jre > > Do the files have to go in both locations? > > Please give me simple directions as to where each of these three files > should be placed (rxtxSerial.dll, rxtxParallel.dll and RXTXcomm.jar). > > Thanking you in advance, > > Glen. I'm not that familiar with what is right on w32. The dll needs to be in your PATH. The jar file needs to be in your CLASSPATH. The ext directory can be used to make sure that the RXTXcomm.jar is in your CLASSPATH without modifying the environmental variable. I assume this would be Java/jdk1.5.0/jre/lib/ext - some java distributions lack the ext directory as I recall. Usually the 'public' directory just points to the private one. Sun may do this with binaries now but they used to be just shell scripts on UNIX in the 'public' bin directory that setup the environment and then called the 'private' copy. So I would think the dll would go in Java/jdk1.5.0/jre/bin. But as long as the dlls are in your PATH and the jar is in your CLASSPATH, rxtx should work. Its not very clear to me that there is a right way to install the dlls for EXTra/javaX packages on w32. I've always just assumed this was the w32 'dll hell' everyone talks about :) > > -----Original Message----- > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > Behalf Of Trent Jarvi > Sent: 23 October 2004 23:43 > To: Java RXTX discussion > Subject: RE: [Rxtx] Question regarding current versions > > > On Sat, 23 Oct 2004, Dodger wrote: > > > Hi Trent, > > > > Thanks so much for your assistance so far. > > > > I decided to go with the binaries on the download page, 'rxtx-2.1-7pre17', > > as I'm not too clued up on CVS/build files etc., yet. Just copied the > native > > library and the rxtx jar file; I assume that is all that is required for > > serial comms.? > > > > Anyway...It's working; But, I get an error when doing a simple > enumeration, > > the complete output follows: > > > > Version: RXTX-2.1-7pre17 > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS0: File > exists > > /dev/ttyS1 > > > > I can post the source if necessary. It just prints the version information > > and then enumerates the available serial ports. > > > > I think that that port may be being used by my modem, and the modem may > hold > > a lock on it. If this is so, is this normal behaviour? > > > > Environment: Red Hat 8.0, Java - JDK 1.5.0 > > > > > If the program fails to close a port, the file will still be there. If > you have a program running in another terminal or in the background, the > lock file will be there and for good reason. Inside the lockfile is the > PID of the application that left the lockfile. > > ps up `< /var/lock/LCK..ttyS0` > > Should show which application has the lock. > > ps up `< /var/lock/LCK..ttyS0` > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jarvi 13438 1.6 0.9 1354868 37804 pts/15 T 15:50 0:00 java > BlackBox -p /de > > Make sure your user is in group lock > > /etc/group > > ... > lock:x:54:rm-rf,jarvi,rxtx > ... > > places users rm-rf, jarvi and rxtx in group lock. Full distributions have > locking libraries that rxtx could use but these are not available on all > systems. > > Finally, make sure your application closes the port before exiting. > > If the modem is using /dev/ttyS0 you should be glad that rxtx didnt try > taking the modem. It would have killed your internet connection. More > often, someone runs an application in one window and then runs it again in > another window. The idea is to prevent applications from reading each > others data. The messages are printed so people know why enumeration > comes up with no available ports when something else has them open. > > > > > -----Original Message----- > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > Behalf Of Trent Jarvi > > Sent: 23 October 2004 19:21 > > To: Java RXTX discussion > > Subject: RE: [Rxtx] Question regarding current versions > > > > > > On Sat, 23 Oct 2004, Dodger wrote: > > > > > Thanks Trent, > > > > > > And as far as portability is concerned? In the case of v2.0 does it just > > > mean that you have to ensure 2 different things are setup correctly for > > each > > > installation (RXTX and Commapi), as apposed to one (RXTX) (?) > > > > > > Finally, is 'Crash in JVM 1.5.0 with 2.1-7pre17' likely to affect all > > linux > > > users, or does it only occur under specific conditions? > > > > > > Thanks again, > > > > > > > The crash in JVM 1.5.0 was more than just a Linux issue. I'm fairly sure > > this is what was causing problems on BSD and slower w32 machines with > > earlier JVMs too. We have the fix in 2.1 CVS but I have not had time to > > bring the changes to 2.0 CVS yet. > > > > All OSs with rxtx 2.0 are 'UNIX Like' there is a POSIX like layer included > > for those that need it. So all OSs use Suns CommAPI for Solaris (even > > w32) and a javax.comm.properties file. > > > > RXTX 2.1 exposes some methods that are not part of CommAPI and are > > documented as extensions. These are not recommeneded but are available in > > 2.1 so its under a completely different namespace. Code can move from > > javax.comm to gnu.io with just a change in the package name for the most > > part but code using gnu.io exensions to commapi can not move back to > > javax.comm without modification (removal of the extensions). > > > > What I'd recommend right now is using rxtx 2.1 from CVS with only Sun > > documented Methods. The package can be changed to javax.comm and comm.jar > > can be used with rxtx 2.0 later. There are a few people chasing each > > other with vacations but I expect the code in 2.1 CVS is going to be > > released as 2.1.7 and 2.0.7 the second week of November after some formal > > testing. > > > > export > > CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot > > cvs login (mousy for password) > > cvs checkout -r commapi-0-0-1 rxtx-devel > > cd rxtx-devel > > mkdir build > > cd build && ../configure && make install > > > > w32 bins (minus some 64 bit fixes which are not needed) can be obtained at > > ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7pre19-i386-pc-mingw32.zip > > > > > Glen. > > > > > > -----Original Message----- > > > From: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]On > > > Behalf Of Trent Jarvi > > > Sent: 22 October 2004 09:37 > > > To: Java RXTX discussion > > > Subject: Re: [Rxtx] Question regarding current versions > > > > > > > > > On Fri, 22 Oct 2004, Dodger wrote: > > > > > > > Hi again, > > > > > > > > Not sure what happened the first time, but anyway, here goes again... > > > > > > > > I just wanted to start off with a quick question regarding version > > choice, > > > > and later I may (probably will) require some assistance with the > actual > > > > installation if possible. > > > > > > > > Question (1): > > > > > > > > I'm not sure I understand the difference/s between versions 2.0 and > 2.1. > > > Is > > > > it only a change in API? The one API matching that of Sun, and the > other > > a > > > > non-Sun compliant API? Essentially the question is: What version > should > > I > > > be > > > > using? And what are the pro's and con's of each? > > > > > > > > TIA. > > > > > > > > Glen. > > > > > > > > > > > > > rxtx 2.1 is a full library and does not require any files from Sun. Its > > > package name is different to avoid conflicting with Sun's namespace but > > > otherwise its the same. The same methods and classes are available. > > > > > > rxtx 2.0 is the same code but works with Sun's commapi and is under > Sun's > > > namespace. > > > > > > Its all the same code underneath. So The choice is just that. You can > > > use either one. There shouldnt be any advantage of one over the other. > > > When the package is released, the same code is just modified to match > the > > > packages. > > > > > > -- > > > Trent Jarvi > > > taj at www.linux.org.uk > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at linuxgrrls.org > > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From neil.benn at gmail.com Sun Oct 24 16:04:19 2004 From: neil.benn at gmail.com (Neil Benn) Date: Sun, 24 Oct 2004 22:04:19 +0000 Subject: [Rxtx] Windows CE Message-ID: Hello, I'm looking for a build of the windows CE port. Does anyone have one available that they could send me (including the corresponding properties and jar files). I can't find the windows CE build. Any and all help is greatly appreciated. Cheers, Neil From taj at www.linux.org.uk Sun Oct 24 16:30:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sun, 24 Oct 2004 23:30:09 +0100 (BST) Subject: [Rxtx] Windows CE In-Reply-To: References: Message-ID: On Sun, 24 Oct 2004, Neil Benn wrote: > Hello, > > I'm looking for a build of the windows CE port. Does anyone > have one available that they could send me (including the > corresponding properties and jar files). I can't find the windows CE > build. > > Any and all help is greatly appreciated. > Hi Neil I see there are binaries in rxtx-2.1-6 rxtx-2.1-6.tar.gz -rwxr--r-- root/root 30208 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMDbg/rxtxSerial.dll -rwxr--r-- root/root 19456 2002-09-07 16:13:04 rxtx-2.1-6/WinCE/ARMRel/rxtxSerial.dll These may be dated. I dont know if anyone has built them in a while. There are probably fixes needed to build from current source. The binaries in those files go back to 2002-04-05/rxtx-2.1-2. ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-2.tar.gz would probably be the best place to start. There is a copy of the jar in the MACOSX directory. rxtx-2.1-2/MACOSX_IDE/CW/RXTXcomm.jar Michal Hobbit did the WinCE port. He put a page up at: http://www.mhobot.w.pl/java/comm which also links to an archive of the build he did: http://republika.pl/mho/java/comm/RXTX_iPAQ_0211.zip Along with other options he found at the time. I'm not sure Michal has looked at this in a long time and I've never had a build environment setup for WinCE. -- Trent Jarvi taj at www.linux.org.uk From dessarps at bktel.com Sun Oct 31 02:50:07 2004 From: dessarps at bktel.com (Philippe Dessarps) Date: Sun, 31 Oct 2004 10:50:07 +0100 Subject: [Rxtx] ttyS0 not found Message-ID: <4184B54F.6070608@bktel.com> Hi, i would like to connect a modem to the serial port of my Linux FC1 and run my java application with rxtx. Minicom can connect to the modem on port /dev/ttyS0, but rxtx cannot find /dev/ttyS0. I find this out by running a piece of code I found in the mail list (Philipp Hofmann posted on 2003-07-01). import gnu.io.*; import java.util.Enumeration; public class Test { public static void main(String[] arg) { System.out.println("start"); Enumeration e = CommPortIdentifier.getPortIdentifiers(); while(e.hasMoreElements()) { System.out.println(((CommPortIdentifier)e.nextElement()).getName()); } System.out.println("stop"); } } with my user it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 stop -- runing under root it returns: start Devel Library ========================================= Native lib Version = RXTX-2.1-7pre17 Java lib Version = RXTX-2.1-7pre17 /dev/lp0 stop Many people seem to have this problem, but it often due to the lock rights. On the Linux, I am member of group "lock and uucp". I can therefore write into /var/lock and can read/write on /dev/ttyS0. The serial port settings seem to be ok. [root at bksys047 test]# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 [root at bksys047 test]# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 Has anybody an idea? thanks in advance Philippe From lonedesign_2k at yahoo.com Sun Oct 31 08:28:47 2004 From: lonedesign_2k at yahoo.com (Dodger) Date: Sun, 31 Oct 2004 17:28:47 +0200 Subject: [Rxtx] Modem/Serial Comm. Problem Message-ID: Hi, I've spent two full days trying to find an answer to this question, without any luck. When I send an AT command to my modem it just echo's it right back at me, instead of sending some form of acknowledgement, such as an OK response code. Of course, this means it doesn't respond correctly to dialling commands either (AT Dnnnnnnn). The problem is this: BlackBox works, as well as another sample application I have -- just not code (typical). Any ideas as to why this is happening? Could it be that my sending and receiving is not done in separate threads? Some info: OS: Windows 2000 JDK: 1.5.0 Modem: 3Com U.S. Robotics 56K Faxmodem My code follows: (Test & _SerialPort) ==[ Test ] public class Test { public static void main(String[] arguments) { _SerialPort port = new _SerialPort(); port.open(); port.write("AT D7152016;\r"); try { Thread.sleep(10000); } catch(InterruptedException e) { System.err.println(e); } port.close(); } } == ==[_SerialPort] import gnu.io.*; import java.io.*; import java.util.TooManyListenersException; public class _SerialPort implements SerialPortEventListener, CommPortOwnershipListener { private CommPortIdentifier portID; private SerialPort serialPort; private InputStream in; private OutputStream out; private byte[] buffer = new byte[2048]; public _SerialPort() { // TODO: Pass parameter object to constructor } public void open() { try { portID = CommPortIdentifier.getPortIdentifier("COM1"); } catch(NoSuchPortException e) { System.err.println(e); } try { serialPort = (SerialPort)portID.open("_SerialPort", 5000); } catch(PortInUseException e) { System.err.println(e); } try { in = serialPort.getInputStream(); out = serialPort.getOutputStream(); } catch(IOException e) { System.err.println(e); } try { serialPort.addEventListener(this); } catch(TooManyListenersException e) { System.err.println(e); } serialPort.notifyOnBreakInterrupt(true); serialPort.notifyOnCarrierDetect(true); serialPort.notifyOnCTS(true); serialPort.notifyOnDataAvailable(true); serialPort.notifyOnDSR(true); serialPort.notifyOnFramingError(true); serialPort.notifyOnOutputEmpty(true); serialPort.notifyOnOverrunError(true); serialPort.notifyOnParityError(true); serialPort.notifyOnRingIndicator(true); portID.addPortOwnershipListener(this); } public void write(String data) { try { out.write(data.getBytes()); } catch(IOException e) { System.err.println(e); } } public void close() { try { // Close the i/o streams in.close(); out.close(); } catch(IOException e) { System.err.println(e); } // Close the port. serialPort.close(); // Remove the ownership listener portID.removePortOwnershipListener(this); } public void serialEvent(SerialPortEvent evt) { switch(evt.getEventType()) { // Break interrupt case SerialPortEvent.BI: System.out.println("Break interrupt"); break; // Carrier detect case SerialPortEvent.CD: System.out.println("Carrier detect"); break; // Clear to send case SerialPortEvent.CTS: System.out.println("Clear to send"); break; // Data available at the serial port case SerialPortEvent.DATA_AVAILABLE: int count; try { while(in.available() > 0) { count = in.read(buffer); if(count > 0) { if(count > buffer.length) { System.err.println("Input buffer overflow"); } System.out.println(new String(buffer, 0, count)); } } } catch(IOException e) { System.err.println(e); } break; // Data set ready case SerialPortEvent.DSR: System.out.println("Data set ready"); break; // Framing error case SerialPortEvent.FE: System.out.println("Framing error"); break; // Overrun error case SerialPortEvent.OE: System.out.println("Overrun error"); break; // Output buffer is empty case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Output buffer is empty"); break; // Parity error case SerialPortEvent.PE: System.out.println("Parity error"); break; // Ring indicator case SerialPortEvent.RI: System.out.println("Ring indicator"); break; } } public void ownershipChange(int type) { switch(type) { case CommPortOwnershipListener.PORT_OWNED: System.out.println("PORT_OWNED"); break; case CommPortOwnershipListener.PORT_OWNERSHIP_REQUESTED: System.out.println("PORT_OWNERSHIP_REQUESTED"); break; case CommPortOwnershipListener.PORT_UNOWNED: System.out.println("PORT_UNOWNED"); break; } } } == If you have any other working sample code for serial/modem i/o, please send it my way. Thanks, Glen. From dsummersl at yahoo.com Fri Oct 1 08:24:06 2004 From: dsummersl at yahoo.com (dsummersl@yahoo.com) Date: Fri, 1 Oct 2004 10:24:06 -0400 Subject: [Rxtx] RXTX || in windows XP Message-ID: <20041001142406.GC10485@tender> Hi, I'm trying to get the RXTX || support to work bidirectionally. Thus far I have tried the following: I have tried to use both the binary version 2.0-7pre1 listed on the rxtx.org website as well as 2.1-7pre17 (changing my sources accordingly), and I have compiled the CVS head with mingw. With 2.0-7pre1 within Sun's comm interface...I have limited success. I can retrieve the outputStream, but if I try the inputStream I will get an UnsatisfiedLinkError(: Initialize). I've also used mingw to build the DLLs myself - but I don't think I did it right :) They produced an entirely different error: UnsatisfiedLinkError: nativeGetVersion while loading driver gnu.io.RXTXCommDriver. So. I'm scratching my head at the moment. But, I took your advise and signed up to the mailing list. I'll try all things things over again in a couple days. Thanks, Dane On Tue, Sep 28, 2004 at 04:18:38PM +0100, Trent Jarvi wrote: > > The project is fairly slow at the moment. Small patches now and then. We > had a big push for some companies with the pre patches and things slowed > down when it worked for them. I do most of the coding and it goes in > bursts when companies contract faster solutions. > > Windows Parallel support has been reported to work for some but to be > honest I have never tested the bidirectional portion. I have tried to > put any patches into CVS that people send back. > > Sometimes, rxtx 2.0 gets minor mistakes in releases when it tries to use > gnu.io package instead of javax.comm. This sounds like it may be an error > of that sort. But right now I can suggest two things: > > 1) join the rxtx mail list and ask there. Its ~5 emails a week > and 0 spam. There are active people that just read it. > 2) Let me know which rxtx version you are using and if you > are compiling it yourself. I need to at least know what to > look at :) > > Getting simple bidirectional support to work shouldnt be too bad. The > extended pport functionality beyond that is ... just a rough outline in > the code. I dont think Sun spent very much time thinking about or > implementing the advanced stuff. RXTX has done perhaps a little more than > they did on the implementation side. But its not a road well traveled. > > On Tue, 28 Sep 2004 dsummersl at yahoo.com wrote: > > > Hello, > > > > I am trying to find an IO package for Java that has both in/out parallel > > support for Windows 2000/Windows XP. It *looks* like RXTX does this, > > however, when I tried out the driver I get "java.io.IOException: The > > specified procedure could not be found. in nativeavailable" (I have > > tried this for all valid 'port.setMode's). Does this mean > > 'nativeavailable' is not implemented? I've looked around the code a > > little and I see that there is a nativeavailable method in > > 'ParallelImp.c' and it looks like something is implemented therein. > > > > Is this project still going on? CVS looks to have very little traffic > > in the last six months. > > > > What is the status of parallel support for this driver, and if it is not > > yet working, do you have any ideas of how close it would be to > > completing? > > > > Thanks for your time, > > > > Dane Summers > > > > > > -- > Trent Jarvi > taj at www.linux.org.uk > From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue, 05 Oct 2004 21:01:24 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 Message-ID: <416343E4.1030806@gladstonefamily.net> Hi, I get a reproducible crash in my jvm running on linux. The stack backtrace shows: Stack: [0xbfe00000,0xc0000000), sp=0xbfffc7ac, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j gnu.io.RXTXPort.sendEvent(IZ)Z+183 v ~StubRoutines::call_stub V [libjvm.so+0x24e2dc] V [libjvm.so+0x3e22d8] V [libjvm.so+0x24e10f] V [libjvm.so+0x26fdc3] V [libjvm.so+0x258dda] C [librxtxSerial.so+0x6eb3] send_event+0xc3 C [librxtxSerial.so+0x3e4c] Java_gnu_io_RXTXPort_nativeDrain+0x10c j gnu.io.RXTXPort.nativeDrain(Z)Z+0 j gnu.io.RXTXPort$SerialOutputStream.flush()V+72 j com.dalsemi.onewire.adapter.SerialService.flush()V+21 j com.dalsemi.onewire.adapter.USerialAdapter.uTransaction(Lcom/dalsemi/onewire/adapter/UPacketBuilder;)[C+4 j com.dalsemi.onewire.adapter.USerialAdapter.search(Lcom/dalsemi/onewire/adapter/OneWireState;)Z+98 j com.dalsemi.onewire.adapter.USerialAdapter.isPresent([B)Z+91 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j net.gladstonefamily.onewire.WrapperAdapter.isPresent([B)Z+5 j com.dalsemi.onewire.container.OneWireContainer.doSpeed()V+24 j com.dalsemi.onewire.container.OneWireContainer26.readPage(I)[B+60 j com.dalsemi.onewire.container.OneWireContainer26.readDevice()[B+12 j net.gladstonefamily.onewire.lantest.main([Ljava/lang/String;)V+695 v ~StubRoutines::call_stub I'm running with -Xint to eliminate any problems with the JIT. THe problem seems fairly immune to timing -- I have turned on various bits of debug in the rxtx code and it always happens (altthough it sometimes takes longer). I also tried 2.1-6, but that behaved in the same way. I also tried JVM 1.4.2 and that also crashed. I've poked about a bit, but I'm currently at a loss for where to go next. Any suggestions? Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/d6d2df74/smime-0004.bin From daniel at readytechnology.co.uk Tue Oct 5 19:02:28 2004 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Wed, 06 Oct 2004 02:02:28 +0100 Subject: [Rxtx] reading from a USB serial port fails Message-ID: <41634424.5070608@readytechnology.co.uk> I have two serial ports: /dev/ttyS0 /dev/ttyS100 linked to /dev/ttyUSB0 I have modified the Java demo program SimpleRead.java to read from the USB serial port at 1200 bps and echo the input byte numerically (eg, if it reads an A, it echos 65). When I join the two ports with a null modem cable, and open /dev/ttyS0 with minicom, the characters I type are echoed by SimpleRead. When I connect my hardware device to /dev/USB0, 0's are read from the input stream (that's write, ASCII code 0, not the number 0). There is one 0 read from the stream for every character sent by my hardware device. The same hardware device connected to /dev/ttyS0 and SimpleRead works fine, reading the characters sent by the device. From fernandezm22 at yahoo.com.ar Tue Oct 5 19:53:05 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue, 5 Oct 2004 22:53:05 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? Message-ID: <200410052253.13216.fernandezm22@yahoo.com.ar> Hi, I want to communicate to an external modem, to be able to get Caller ID information when someone is calling (this is by sending AT commands) with Java/Linux-Windows. That's when I get to www.rxtx.org. I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the like in /dev/ttyS1). I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and recompile the example. But when I try to run the program, it crashes: "Unexpected Signal : 11 occurred at PC=0x426AFCB2 Function=[Unknown.] Library=(N/A) NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) ........." I searched through this forum, and found this workarounds: http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 I added the usleep() calls in the source (Bernd Pachur message), recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) and I get the same results (a very slow program, I can't do anything but close it). Unfortunately, I don't know a lot of C programming (I would help...), but it seems like it happends on all 'new' kernels... right? My question is: it this problem solved in CVS, or sould I try an old 1.5.x rxtx version, or should I wait till next release? (when it is going to be?) I'm looking at another solutions to do this (for example, Perl has an Modem multiplatform module to send/receive AT commands), but I don't want to send/receive messages between Perl and Java (I want to do the UI in Java/Swing). Thanks a lot Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041005/c221170c/attachment-0004.bin From taj at www.linux.org.uk Tue Oct 5 21:04:37 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:04:37 +0100 (BST) Subject: [Rxtx] reading from a USB serial port fails In-Reply-To: <41634424.5070608@readytechnology.co.uk> References: <41634424.5070608@readytechnology.co.uk> Message-ID: On Wed, 6 Oct 2004, Daniel Pocock wrote: > > > I have two serial ports: > /dev/ttyS0 > /dev/ttyS100 linked to /dev/ttyUSB0 This should not cause any issues. One can also add ttyUSB to RXTXCommDriver.java or modify the .properties file and use it directly but that will not cause any behavior differnces. > > I have modified the Java demo program SimpleRead.java to read from the > USB serial port at 1200 bps and echo the input byte numerically (eg, if > it reads an A, it echos 65). > > When I join the two ports with a null modem cable, and open /dev/ttyS0 > with minicom, the characters I type are echoed by SimpleRead. so ttyS0 minicom write -> ttyUSB SimpleRead read is working. > > When I connect my hardware device to /dev/USB0, 0's are read from the > input stream (that's write, ASCII code 0, not the number 0). There is > one 0 read from the stream for every character sent by my hardware device. > > The same hardware device connected to /dev/ttyS0 and SimpleRead works > fine, reading the characters sent by the device. > so gadget write -> ttyUSB SimpleRead read is not working as expected. gadget write -> ttyS0 SimpleRead read is working. yikes. I'm guessing that something in the USB driver has a slightly different default than the the normal driver. I would explicity state the buad rate, parity, stop bits, flow control, timeouts and thresholds in your simpleread. If you still see problems add a printf in the native read_byte_array(). This is where the read actually happens. You can follow from there what is going on. The file is SerialImp.c the printf may look like the following: ... else if (ret > 0) { if ((ret = READ( fd, buffer + bytes, left )) < 0 ){ if (errno != EINTR && errno != EAGAIN){ report( "read_byte_array: read returned -1\n" ); LEAVE( "read_byte_array" ); eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } eis->eventflags[SPE_DATA_AVAILABLE] = flag; return -1; } printf("READ %i bytes chars = %s\n", ret, buffer + bytes); else if ( ret ) { The code with USB that notifies users when data is available is probably different on ttyUSB vs ttyS. I'd expect the USB driver to be lacking on some event information like output buffer empty that is going to use more rxtx code. But I'd cut right to the READ code above. Its behavior is documented in the read man page. I suspect the ports just have a slightly different default. Even though you saw it work between ttyS and ttyUSB. USB does work on Mac OS X. This cant be a huge bug. but something like a different port setting could explain it. Is the data available event happening when you expected? Are you sure the read didnt just timeout? -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 04:12:48 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410052253.13216.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > Hi, I want to communicate to an external modem, to be able to get Caller ID > information when someone is calling (this is by sending AT commands) with > Java/Linux-Windows. That's when I get to www.rxtx.org. > > I'm using J2SE 1.4.2_05, and Debian Sarge updated daily (kernel 2.6.7-i686 > from Debian) in a Pentium III 733 with 384 Ram. My modem is an old 'real' > Zoltrix 33600 modem, and minicom opens it right (I can do ATDTxxxx and the > like in /dev/ttyS1). > > I compiled 2.1-7pre17 from source, installed, renamed in the BlackBox example > (from Sun Solaris Comm package) all imports (javax.comm to gnu.io.*), and > recompile the example. > > But when I try to run the program, it crashes: > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > Function=[Unknown.] > Library=(N/A) > > NOTE: We are unable to locate the function name symbol for the error > just occurred. Please refer to release documentation for possible > reason and solutions. > > > Current Java thread: > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > ........." Nods, I just started looking at this seriously last weekend. Its not a one line fix but as you noted from the mail list there are work arounds. We need to fix the underlying problem. > > I searched through this forum, and found this workarounds: > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > I added the usleep() calls in the source (Bernd Pachur message), recompiled > and BlackBox runs, but... veeery slooow... (it takes all CPU - 100 %). > I tried with the another workaround (compile with 1.4.2 and run with 1.5.0) > and I get the same results (a very slow program, I can't do anything but > close it). > > Unfortunately, I don't know a lot of C programming (I would help...), but it > seems like it happends on all 'new' kernels... right? > > My question is: it this problem solved in CVS, or sould I try an old 1.5.x > rxtx version, or should I wait till next release? (when it is going to be?) > > I'm looking at another solutions to do this (for example, Perl has an Modem > multiplatform module to send/receive AT commands), but I don't want to > send/receive messages between Perl and Java (I want to do the UI in > Java/Swing). > > Thanks a lot > Marcelo > I suspect this is the eventLoop in the native code. While data is available and unread, that loop can spin very fast. It is possible a poll instead of a select implementation could slow the loop down. But the easy solution is to just have the eventLoop perform usleep(10000); between sending the data available events. This used to be in the code but I think someone complained that they did not recieve enough data available events. There are a couple of places this can happen depending upon the ports capabilities but you can just add it after sending the event and it should throttle the loop down. send_event( &eis, SPE_DATA_AVAILABLE, 1 ); usleep(10000); /* 10 ms */ -- Trent Jarvi taj at www.linux.org.uk From fernandezm22 at yahoo.com.ar Wed Oct 6 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Wed, 6 Oct 2004 03:30:51 -0300 Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: References: <200410052253.13216.fernandezm22@yahoo.com.ar> Message-ID: <200410060330.56956.fernandezm22@yahoo.com.ar> El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > Hi, I want to communicate to an external modem, to be able to get Caller > > ID information when someone is calling (this is by sending AT commands) > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > ..... > > But when I try to run the program, it crashes: > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > Function=[Unknown.] > > Library=(N/A) > >.... > > Current Java thread: > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > ........." > > Nods, I just started looking at this seriously last weekend. Its not a > one line fix but as you noted from the mail list there are work arounds. > We need to fix the underlying problem. > > > I searched through this forum, and found this workarounds: > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > I added the usleep() calls in the source (Bernd Pachur message), > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > with 1.5.0) and I get the same results (a very slow program, I can't do > > anything but close it). > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > it seems like it happends on all 'new' kernels... right? > > > > My question is: it this problem solved in CVS, or sould I try an old > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > to be?) > > > > I'm looking at another solutions to do this (for example, Perl has an > > Modem multiplatform module to send/receive AT commands), but I don't want > > to send/receive messages between Perl and Java (I want to do the UI in > > Java/Swing). > > > > Thanks a lot > > Marcelo > > I suspect this is the eventLoop in the native code. While data is > available and unread, that loop can spin very fast. It is possible a poll > instead of a select implementation could slow the loop down. But the easy > solution is to just have the eventLoop perform usleep(10000); between > sending the data available events. This used to be in the code but I > think someone complained that they did not recieve enough data available > events. > > There are a couple of places this can happen depending upon the ports > capabilities but you can just add it after sending the event and it should > throttle the loop down. > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > usleep(10000); /* 10 ms */ Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 in SerialImp.c and I get the same error.... (it is the only line with send_event( &eis, SPE_DATA_AVAILABLE, 1 )). It is strange, but that line is inside an #ifdef WIN32.... I was afraid that code didn't execute in my linux box, so after that I added another line before the while(1)... and guess what? still crashes.... :-( To be honest, I'm not in a hurry with this, I'm just evaluating how to send AT commands to the modem, but it will be in a couple of months. So, take your time to analize the bug and fix the underlying problem. I'm glad you already are looking for solutions. I'm sorry I can't help you with C code, but if you want me to test something, or do anything to help you, I will. Meanwhile, I'll be following the progress of the project. (Sorry for my english!) Thanks! Marcelo -- Marcelo F. Fern?ndez Buenos Aires, Argentina Analista de Sistemas - CCNA E-Mail: fernandezm22 at yahoo.com.ar Jabber ID: fernandezm22 at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/da013742/attachment-0013.bin From taj at www.linux.org.uk Wed Oct 6 01:17:28 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 6 Oct 2004 08:17:28 +0100 (BST) Subject: [Rxtx] "FC2" Crash Signal 11 also in Debian - What to do? In-Reply-To: <200410060330.56956.fernandezm22@yahoo.com.ar> References: <200410052253.13216.fernandezm22@yahoo.com.ar> <200410060330.56956.fernandezm22@yahoo.com.ar> Message-ID: On Wed, 6 Oct 2004, Marcelo Fernandez wrote: > El Mi?rcoles, 06 de Octubre de 2004 00:12, Trent Jarvi escribi?: > > On Tue, 5 Oct 2004, Marcelo Fernandez wrote: > > > Hi, I want to communicate to an external modem, to be able to get Caller > > > ID information when someone is calling (this is by sending AT commands) > > > with Java/Linux-Windows. That's when I get to www.rxtx.org. > > > ..... > > > But when I try to run the program, it crashes: > > > > > > "Unexpected Signal : 11 occurred at PC=0x426AFCB2 > > > Function=[Unknown.] > > > Library=(N/A) > > >.... > > > Current Java thread: > > > at gnu.io.RXTXPort.NativeisReceiveTimeoutEnabled(Native Method) > > > at gnu.io.RXTXPort.isReceiveTimeoutEnabled(RXTXPort.java:382) > > > ........." > > > > Nods, I just started looking at this seriously last weekend. Its not a > > one line fix but as you noted from the mail list there are work arounds. > > We need to fix the underlying problem. > > > > > I searched through this forum, and found this workarounds: > > > http://marc.theaimsgroup.com/?l=rxtx&m=108963250816383&w=2 > > > http://marc.theaimsgroup.com/?l=rxtx&m=108798744401772&w=2 > > > > > > I added the usleep() calls in the source (Bernd Pachur message), > > > recompiled and BlackBox runs, but... veeery slooow... (it takes all CPU - > > > 100 %). I tried with the another workaround (compile with 1.4.2 and run > > > with 1.5.0) and I get the same results (a very slow program, I can't do > > > anything but close it). > > > > > > Unfortunately, I don't know a lot of C programming (I would help...), but > > > it seems like it happends on all 'new' kernels... right? > > > > > > My question is: it this problem solved in CVS, or sould I try an old > > > 1.5.x rxtx version, or should I wait till next release? (when it is going > > > to be?) > > > > > > I'm looking at another solutions to do this (for example, Perl has an > > > Modem multiplatform module to send/receive AT commands), but I don't want > > > to send/receive messages between Perl and Java (I want to do the UI in > > > Java/Swing). > > > > > > Thanks a lot > > > Marcelo > > > > I suspect this is the eventLoop in the native code. While data is > > available and unread, that loop can spin very fast. It is possible a poll > > instead of a select implementation could slow the loop down. But the easy > > solution is to just have the eventLoop perform usleep(10000); between > > sending the data available events. This used to be in the code but I > > think someone complained that they did not recieve enough data available > > events. > > > > There are a couple of places this can happen depending upon the ports > > capabilities but you can just add it after sending the event and it should > > throttle the loop down. > > > > send_event( &eis, SPE_DATA_AVAILABLE, 1 ); > > usleep(10000); /* 10 ms */ > > Ummm... sorry, but it didn't work. I added usleep(10000) in line number 3950 > in SerialImp.c and I get the same error.... (it is the only line with > send_event( &eis, SPE_DATA_AVAILABLE, 1 )). > > It is strange, but that line is inside an #ifdef WIN32.... I was afraid that > code didn't execute in my linux box, so after that I added another line > before the while(1)... and guess what? still crashes.... :-( > Right, thats w32 code and is compiled out on Linux. The Data available events are happening in the eventLoop(); when report_serial_events( ); Is called. In fact you can try sleeping in the mail do{}while in eventLoop; just to get it under control. I'm fairly sure its data available thats causing problems. The selects wont block in that case. If you look at report_serial_events, you will see where data available is checked. The only other code that could be spinning that I can think of off hand would be the void *drain_loop( void *arg ) which is used for ports with less cababilities to determine when the output buffer is empty. -- Trent Jarvi taj at www.linux.org.uk From philip at gladstonefamily.net Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Wed, 06 Oct 2004 22:29:02 -0400 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <416343E4.1030806@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> Message-ID: <4164A9EE.2040405@gladstonefamily.net> Philip Gladstone wrote: > Hi, > > I get a reproducible crash in my jvm running on linux. The stack > backtrace shows: > After a bit more poking around, I think that I found my problem. It turns out that the nativeDrain function was calling send_event which then used the JNIEnv pointer from the wrong thread. This is (apparently) a big nono. The attached patch fixes that problem, and also fixes a problem on SuSE linux (the lock directories are not all distinct -- some are symlinked to each other. This causes problems if there are surplus lock files). After applying this patch, my system has been running for a couple of hours, where it used to crash within minutes. Philip -- Philip Gladstone * Check out the live pondcam at http://pond.gladstonefamily.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre17.pf Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/pre17-0004.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3322 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20041006/113b5978/smime-0004.bin From taj at www.linux.org.uk Wed Oct 6 20:48:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 03:48:26 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <4164A9EE.2040405@gladstonefamily.net> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: On Wed, 6 Oct 2004, Philip Gladstone wrote: > Philip Gladstone wrote: > > > Hi, > > > > I get a reproducible crash in my jvm running on linux. The stack > > backtrace shows: > > > After a bit more poking around, I think that I found my problem. It > turns out that the nativeDrain function was calling send_event which > then used the JNIEnv pointer from the wrong thread. This is (apparently) > a big nono. > > The attached patch fixes that problem, and also fixes a problem on SuSE > linux (the lock directories are not all distinct -- some are symlinked > to each other. This causes problems if there are surplus lock files). > > After applying this patch, my system has been running for a couple of > hours, where it used to crash within minutes. > Hi Philip Wow. I've been trying to read into how to solve this and was trying something much messier. In fact I was more or less stuck in a dead end the direction I was going. I would be very interested in hearing if this works for others. -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 20:02:00 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> Message-ID: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> wait a second I thought we already resolved that problem I even posted some code to retrieve JNIEnv from any arbitrary thread: JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ JNIEnv *env = NULL; if(vm == NULL) return env; wasAttached = false; jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); if(errGetEnv == JNI_ERR) return NULL; if(errGetEnv == JNI_EDETACHED){ vm->AttachCurrentThread((void **)&env,(void *)NULL); if(env != NULL) wasAttached = true; }else if(errGetEnv != JNI_OK) return NULL; return env; } JavaVM *JVM = NULL; ...... bool wasAttached = false; JNIEnv *env = GetJEnv(myJVM,wasAttached); ...... if(wasAttached) myJVM->DetachCurrentThread(); I remember we discussed that issue long time ago On Oct 6, 2004, at 7:48 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Philip Gladstone wrote: > >> Philip Gladstone wrote: >> >>> Hi, >>> >>> I get a reproducible crash in my jvm running on linux. The stack >>> backtrace shows: >>> >> After a bit more poking around, I think that I found my problem. It >> turns out that the nativeDrain function was calling send_event which >> then used the JNIEnv pointer from the wrong thread. This is >> (apparently) >> a big nono. >> >> The attached patch fixes that problem, and also fixes a problem on >> SuSE >> linux (the lock directories are not all distinct -- some are symlinked >> to each other. This causes problems if there are surplus lock files). >> >> After applying this patch, my system has been running for a couple of >> hours, where it used to crash within minutes. >> > > Hi Philip > > Wow. I've been trying to read into how to solve this and was trying > something much messier. In fact I was more or less stuck in a dead end > the direction I was going. I would be very interested in hearing if > this > works for others. > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 7 Oct 2004 04:23:53 +0100 (BST) Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: On Wed, 6 Oct 2004, Dmitry Markman wrote: > wait a second > > I thought we already resolved that problem > > I even posted some code to retrieve JNIEnv from any arbitrary thread: > > > JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ > JNIEnv *env = NULL; > if(vm == NULL) return env; > wasAttached = false; > > jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); > if(errGetEnv == JNI_ERR) return NULL; > if(errGetEnv == JNI_EDETACHED){ > vm->AttachCurrentThread((void **)&env,(void *)NULL); > if(env != NULL) wasAttached = true; > }else if(errGetEnv != JNI_OK) return NULL; > return env; > } > > JavaVM *JVM = NULL; > ...... > bool wasAttached = false; > JNIEnv *env = GetJEnv(myJVM,wasAttached); > ...... > if(wasAttached) myJVM->DetachCurrentThread(); > > > I remember we discussed that issue long time ago > > Yes we did discuss this some time ago. It is still outstanding. My confusion was/is with GetJEnv(); This gets a little hard to find documentation on the Internet. So in your code example, you have a NULL *JVM, and then use myJVM. Without very complete documentation this is a little confusing. So on a larger level, is the thread allowed to have a pointer to the JNIEnv? My confusion comes from trying to figure out how to find the JNIEnv from a thread with no pointers. Its safe to store the *JNIEnv in a thread? -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Thu Oct 7 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 6 Oct 2004 23:34:52 -0700 Subject: [Rxtx] Crash in JVM 1.5.0 with 2.1-7pre17 In-Reply-To: References: <416343E4.1030806@gladstonefamily.net> <4164A9EE.2040405@gladstonefamily.net> <421E9E46-180D-11D9-9300-000A95DA5E9C@mac.com> Message-ID: no I don't have NULL JVM I just put ..... usually I cache JVM every jni based library has a callback: JavaVM *JVM = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { JVM = vm; return JNI_VERSION_1_4; // returns whatever you need to return here } JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *vm, void *reserved) { printf("JNI_OnUnload\n");// do whatever you have to do on unload } so now you can use that JVM in any thread On Oct 6, 2004, at 8:23 PM, Trent Jarvi wrote: > On Wed, 6 Oct 2004, Dmitry Markman wrote: > >> wait a second >> >> I thought we already resolved that problem >> >> I even posted some code to retrieve JNIEnv from any arbitrary thread: >> >> >> JNIEnv *GetJEnv(JavaVM *vm,bool &wasAttached){ >> JNIEnv *env = NULL; >> if(vm == NULL) return env; >> wasAttached = false; >> >> jint errGetEnv = vm->GetEnv((void **)&env, JNI_VERSION_1_4); >> if(errGetEnv == JNI_ERR) return NULL; >> if(errGetEnv == JNI_EDETACHED){ >> vm->AttachCurrentThread((void **)&env,(void *)NULL); >> if(env != NULL) wasAttached = true; >> }else if(errGetEnv != JNI_OK) return NULL; >> return env; >> } >> >> JavaVM *JVM = NULL; >> ...... >> bool wasAttached = false; >> JNIEnv *env = GetJEnv(myJVM,wasAttached); >> ...... >> if(wasAttached) myJVM->DetachCurrentThread(); >> >> >> I remember we discussed that issue long time ago >> >> > > > Yes we did discuss this some time ago. It is still outstanding. My > confusion was/is with GetJEnv(); > > This gets a little hard to find documentation on the Internet. So in > your > code example, you have a NULL *JVM, and then use myJVM. Without very > complete documentation this is a little confusing. > > So on a larger level, is the thread allowed to have a pointer to the > JNIEnv? My confusion comes from trying to figure out how to find the > JNIEnv from a thread with no pointers. > > Its safe to store the *JNIEnv in a thread? > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From allen at rrsg.ee.uct.ac.za Fri Oct 8 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Fri, 8 Oct 2004 17:47:31 +0200 Subject: [Rxtx] InputStream.close hangs Message-ID: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Hi, I appear to be having difficulty closing the input stream for the serial port under linux. InputStream.close( ) does not return, and the last InputStream.read( ) remains hanging until some new input appears on the line. This is a major problem for my application since I am not expecting any input. Is this a bug or am I doing something stupid? I have tried closing the input stream, output stream and serial port itself in different orders, what order should I close these resources in? thanks Allen Wallis From taj at www.linux.org.uk Fri Oct 8 18:02:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Sat, 9 Oct 2004 01:02:53 +0100 (BST) Subject: [Rxtx] InputStream.close hangs In-Reply-To: <20041008154731.GA5664@rrsg.ee.uct.ac.za> References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: On Fri, 8 Oct 2004, Allen Wallis wrote: > Hi, > > I appear to be having difficulty closing the input stream for the serial > port under linux. InputStream.close( ) does not return, and the last > InputStream.read( ) remains hanging until some new input appears on the > line. This is a major problem for my application since I am not > expecting any input. Is this a bug or am I doing something stupid? I > have tried closing the input stream, output stream and serial port > itself in different orders, what order should I close these resources > in? > I think you want to set a timeout value for the reads. This is a problematic situation because a slow connection may be finishing a read. or The general solution with the way commapi is designed is to use the data available event and then read the data when the event is recieved. Its possible to see how much data is waiting on the port when the event is recieved so read() does not have to wait for data that may not come. -- Trent Jarvi taj at www.linux.org.uk From alexandre.ricciardi at free.fr Sat Oct 9 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Sat, 09 Oct 2004 10:09:19 +0200 Subject: [Rxtx] InputStream.close hangs In-Reply-To: References: <20041008154731.GA5664@rrsg.ee.uct.ac.za> Message-ID: <41679CAF.8030404@free.fr> Hi, I have just installed rxtx on jdk 1.4.2_05, i get the following error message, that i don't understand : alex at corto:~/Desktop/tini1_13/tini1.13/bin$ java -cp tini.jar -noverify JavaKit An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x40009315 Function=_dl_relocate_object+0x65 Library=/lib/ld-linux.so.2 Current Java thread: at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) - locked <0x44c8c438> (a java.util.Vector) - locked <0x44c947f0> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) - locked <0x44c8b7a8> (a java.lang.Runtime) at java.lang.System.loadLibrary(System.java:834) at gnu.io.RXTXCommDriver.(RXTXCommDriver.java:72) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at javax.comm.CommPortIdentifier.InitializeDriver(CommPortIdentifier.java:213) at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:248) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:351) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Dynamic libraries: 08048000-08056000 r-xp 00000000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 08056000-08059000 rw-p 0000d000 03:01 1387607 /usr/local/java/j2sdk1.4.2_05/bin/java 40000000-40016000 r-xp 00000000 03:01 2219534 /lib/ld-2.3.2.so 40016000-40017000 rw-p 00015000 03:01 2219534 /lib/ld-2.3.2.so 40018000-40020000 r-xp 00000000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40020000-40021000 rw-p 00007000 03:01 147630 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/native_threads/libhpi.so 40021000-40025000 rw-s 00000000 03:01 262102 /tmp/hsperfdata_alex/5884 40025000-40026000 r--p 004bf000 03:01 603894 /usr/lib/locale/locale-archive 40028000-40035000 r-xp 00000000 03:01 2219620 /lib/libpthread-0.10.so 40035000-40037000 rw-p 0000d000 03:01 2219620 /lib/libpthread-0.10.so 40079000-4007b000 r-xp 00000000 03:01 2219573 /lib/libdl-2.3.2.so 4007b000-4007c000 rw-p 00002000 03:01 2219573 /lib/libdl-2.3.2.so 4007d000-401a5000 r-xp 00000000 03:01 2219550 /lib/libc-2.3.2.so 401a5000-401ad000 rw-p 00127000 03:01 2219550 /lib/libc-2.3.2.so 401b0000-405ac000 r-xp 00000000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405ac000-405c7000 rw-p 003fb000 03:01 359800 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/client/libjvm.so 405d9000-405eb000 r-xp 00000000 03:01 2219594 /lib/libnsl-2.3.2.so 405eb000-405ec000 rw-p 00011000 03:01 2219594 /lib/libnsl-2.3.2.so 405ee000-4060f000 r-xp 00000000 03:01 2219589 /lib/libm-2.3.2.so 4060f000-40610000 rw-p 00020000 03:01 2219589 /lib/libm-2.3.2.so 40610000-40613000 r--s 00000000 03:01 392294 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/dnsns.jar 40613000-4061b000 r--s 00000000 03:01 392299 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/comm.jar 4061b000-4061f000 r-xp 00000000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 4061f000-40620000 rw-p 00004000 03:01 1371144 /usr/X11R6/lib/libXtst.so.6.1 40620000-40627000 r-xp 00000000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40627000-40628000 rw-p 00006000 03:01 2219596 /lib/libnss_compat-2.3.2.so 40628000-40630000 r-xp 00000000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40630000-40631000 rw-p 00007000 03:01 2219604 /lib/libnss_nis-2.3.2.so 40631000-40639000 r-xp 00000000 03:01 2219600 /lib/libnss_files-2.3.2.so 40639000-4063a000 rw-p 00008000 03:01 2219600 /lib/libnss_files-2.3.2.so 4063a000-4064a000 r-xp 00000000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064a000-4064c000 rw-p 0000f000 03:01 147637 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libverify.so 4064c000-4066c000 r-xp 00000000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066c000-4066e000 rw-p 0001f000 03:01 147638 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libjava.so 4066e000-40682000 r-xp 00000000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40682000-40685000 rw-p 00013000 03:01 147640 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libzip.so 40685000-42029000 r--s 00000000 03:01 147707 /usr/local/java/j2sdk1.4.2_05/jre/lib/rt.jar 42073000-42089000 r--s 00000000 03:01 147662 /usr/local/java/j2sdk1.4.2_05/jre/lib/sunrsasign.jar 42089000-42166000 r--s 00000000 03:01 147704 /usr/local/java/j2sdk1.4.2_05/jre/lib/jsse.jar 42166000-42177000 r--s 00000000 03:01 147663 /usr/local/java/j2sdk1.4.2_05/jre/lib/jce.jar 42177000-426d0000 r--s 00000000 03:01 147705 /usr/local/java/j2sdk1.4.2_05/jre/lib/charsets.jar 44778000-4477f000 r--s 00000000 03:01 392665 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/RXTXcomm.jar 4c800000-4ca00000 r--p 00000000 03:01 603894 /usr/lib/locale/locale-archive 4ca00000-4ca34000 r--p 00487000 03:01 603894 /usr/lib/locale/locale-archive 4ca34000-4ca50000 r--s 00000000 03:01 391832 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/sunjce_provider.jar 4ca50000-4ca5d000 r--s 00000000 03:01 392574 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/ldapsec.jar 4ca5d000-4cb19000 r--s 00000000 03:01 392664 /usr/local/java/j2sdk1.4.2_05/jre/lib/ext/localedata.jar 4cb19000-4cb3d000 r--s 00000000 03:01 17389 /home/alex/Desktop/tini1_13/tini1.13/bin/tini.jar 4cb3d000-4ce0e000 r-xp 00000000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce0e000-4ce24000 rw-p 002d0000 03:01 147648 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libawt.so 4ce49000-4ce9c000 r-xp 00000000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9c000-4ce9d000 rw-p 00052000 03:01 147647 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libmlib_image.so 4ce9d000-4ce9f000 r-xp 00000000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4ce9f000-4cea0000 rw-p 00001000 03:01 783426 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 4cea0000-4cea8000 r-xp 00000000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea8000-4cea9000 rw-p 00007000 03:01 49180 /usr/lib/libXcursor.so.1.0.2 4cea9000-4ceab000 r-xp 00000000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4ceab000-4ceac000 rw-p 00001000 03:01 1991294 /usr/lib/gconv/ISO8859-15.so 4cead000-4ceb4000 r-xp 00000000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb4000-4ceb5000 rw-p 00006000 03:01 1371125 /usr/X11R6/lib/libXp.so.6.2 4ceb5000-4cf02000 r-xp 00000000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf02000-4cf05000 rw-p 0004d000 03:01 1371140 /usr/X11R6/lib/libXt.so.6.0 4cf06000-4cf13000 r-xp 00000000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf13000-4cf14000 rw-p 0000c000 03:01 1371098 /usr/X11R6/lib/libXext.so.6.4 4cf14000-4cfd8000 r-xp 00000000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfd8000-4cfdb000 rw-p 000c4000 03:01 1371078 /usr/X11R6/lib/libX11.so.6.2 4cfdb000-4cfe3000 r-xp 00000000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe3000-4cfe4000 rw-p 00007000 03:01 1371074 /usr/X11R6/lib/libSM.so.6.0 4cfe4000-4cff8000 r-xp 00000000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cff8000-4cff9000 rw-p 00013000 03:01 1371070 /usr/X11R6/lib/libICE.so.6.3 4cffb000-4d0b5000 r-xp 00000000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0b5000-4d0d0000 rw-p 000b9000 03:01 147651 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/libfontmanager.so 4d0d1000-4d0db000 r-xp 00000000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0db000-4d0dc000 rw-p 00009000 03:01 147708 /usr/local/java/j2sdk1.4.2_05/jre/lib/i386/librxtxSerial.so 4d0e1000-4d0e8000 r-xp 00000000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e8000-4d0e9000 rw-p 00006000 03:01 49189 /usr/lib/libXrender.so.1.2.2 4d0e9000-4d105000 r-xp 00000000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 4d105000-4d107000 rw-p 0001b000 03:01 783425 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Heap at VM Abort: Heap def new generation total 576K, used 499K [0x44780000, 0x44820000, 0x44c60000) eden space 512K, 85% used [0x44780000, 0x447ecdf0, 0x44800000) from space 64K, 99% used [0x44810000, 0x4481fff8, 0x44820000) to space 64K, 0% used [0x44800000, 0x44800000, 0x44810000) tenured generation total 1408K, used 446K [0x44c60000, 0x44dc0000, 0x48780000) the space 1408K, 31% used [0x44c60000, 0x44ccf8b8, 0x44ccfa00, 0x44dc0000) compacting perm gen total 4352K, used 4193K [0x48780000, 0x48bc0000, 0x4c780000) the space 4352K, 96% used [0x48780000, 0x48b98670, 0x48b98800, 0x48bc0000) Local Time = Sat Oct 9 10:03:56 2004 Elapsed Time = 0 # # The ex