From philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue Mar 14 23:21:54 2006 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: Tue Mar 14 23:21:54 2006 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 Mar 14 23:21:54 2006 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.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: Tue Mar 14 23:21:54 2006 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 Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:54 2006 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 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue Mar 14 23:21:54 2006 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.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: Tue Mar 14 23:21:54 2006 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 Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue Mar 14 23:21:54 2006 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.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: Tue Mar 14 23:21:54 2006 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 Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 14 23:21:54 2006 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 Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:54 2006 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 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 14 23:21:54 2006 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 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Tue Mar 14 23:21:54 2006 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: Tue Mar 14 23:21:55 2006 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 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Tue Mar 14 23:21:55 2006 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 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 14 23:21:55 2006 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 philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue Mar 28 18:25:16 2006 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: Tue Mar 28 18:25:16 2006 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 Mar 28 18:25:16 2006 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.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: Tue Mar 28 18:25:16 2006 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 Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:16 2006 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 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue Mar 28 18:25:16 2006 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.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: Tue Mar 28 18:25:16 2006 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 Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue Mar 28 18:25:16 2006 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.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: Tue Mar 28 18:25:16 2006 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 Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:16 2006 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 Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:16 2006 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 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 18:25:16 2006 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 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Tue Mar 28 18:25:16 2006 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: Tue Mar 28 18:25:16 2006 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 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Tue Mar 28 18:25:16 2006 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 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 18:25:16 2006 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 philip at gladstonefamily.net Tue Oct 5 19:01:24 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue Mar 28 20:17:14 2006 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: Tue Mar 28 20:17:14 2006 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 Mar 28 20:17:14 2006 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.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: Tue Mar 28 20:17:14 2006 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 Tue Oct 5 21:12:48 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:14 2006 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 00:30:51 2004 From: fernandezm22 at yahoo.com.ar (Marcelo Fernandez) Date: Tue Mar 28 20:17:14 2006 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.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: Tue Mar 28 20:17:14 2006 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 Wed Oct 6 20:29:02 2004 From: philip at gladstonefamily.net (Philip Gladstone) Date: Tue Mar 28 20:17:14 2006 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.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: Tue Mar 28 20:17:14 2006 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 Wed Oct 6 21:02:00 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:14 2006 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 Wed Oct 6 21:23:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:14 2006 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 00:34:52 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Tue Mar 28 20:17:14 2006 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 09:47:31 2004 From: allen at rrsg.ee.uct.ac.za (Allen Wallis) Date: Tue Mar 28 20:17:14 2006 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: Tue Mar 28 20:17:14 2006 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 02:09:19 2004 From: alexandre.ricciardi at free.fr (alexandre ricciardi) Date: Tue Mar 28 20:17:14 2006 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 02:33:21 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Mar 28 20:17:14 2006 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 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.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 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-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-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 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-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-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 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-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-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 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-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-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 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-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-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 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-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-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 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-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-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 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-0011.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-0011.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/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-0011.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 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-0012.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-0012.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/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-0012.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 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-0013.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-0013.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/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-0013.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 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-0014.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-0014.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-0014.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-0011.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-0014.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 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-0015.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-0015.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-0015.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-0012.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-0015.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 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-0016.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-0016.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-0016.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-0013.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-0016.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 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-0017.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-0017.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-0017.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-0014.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-0017.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 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-0018.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-0018.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-0018.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-0015.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-0018.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 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-0019.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-0019.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-0019.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-0016.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-0019.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 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-0020.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-0020.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-0020.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-0017.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-0020.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 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-0021.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-0021.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-0021.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-0018.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-0021.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 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-0022.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-0022.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-0022.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-0019.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-0022.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 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-0023.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-0023.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-0023.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-0020.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-0023.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 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-0024.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-0024.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-0024.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-0021.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-0024.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 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-0025.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-0025.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-0025.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-0022.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-0025.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 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-0026.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-0026.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-0026.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-0023.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-0026.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 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-0027.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-0027.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-0027.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-0024.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-0027.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 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-0028.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-0028.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-0028.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-0025.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-0028.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 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-0029.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-0029.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-0029.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-0026.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-0029.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 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-0030.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-0030.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-0030.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-0027.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-0030.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 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-0031.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-0031.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-0031.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-0028.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-0031.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 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-0032.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-0032.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-0032.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-0029.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-0032.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 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-0033.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-0033.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-0033.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-0030.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-0033.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 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-0034.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-0034.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-0034.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-0031.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-0034.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 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-0035.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-0035.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-0035.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-0032.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-0035.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 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-0036.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-0036.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-0036.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-0033.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-0036.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 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-0037.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-0037.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-0037.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-0034.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-0037.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 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-0038.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-0038.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-0038.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-0035.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-0038.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 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-0039.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-0039.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-0039.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-0036.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-0039.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 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-0040.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-0040.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-0040.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-0037.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-0040.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 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-0041.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-0041.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-0041.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-0038.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-0041.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 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-0042.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-0042.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-0042.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-0039.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-0042.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 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-0043.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-0043.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-0043.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-0040.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-0043.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 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-0044.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-0044.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-0044.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-0041.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-0044.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 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-0045.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-0045.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-0045.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-0042.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-0045.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 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-0046.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-0046.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-0046.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-0043.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-0046.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 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-0047.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-0047.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-0047.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-0044.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-0047.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 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-0048.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-0048.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-0048.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-0045.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-0048.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 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-0049.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-0049.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-0049.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-0046.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-0049.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 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-0050.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-0050.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-0050.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-0047.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-0050.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 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-0051.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-0051.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-0051.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-0048.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-0051.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 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-0052.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-0052.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-0052.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-0049.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-0052.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 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-0053.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-0053.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-0053.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-0050.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-0053.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 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-0054.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-0054.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-0054.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-0051.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-0054.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 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-0055.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-0055.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-0055.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-0052.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-0055.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 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-0056.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-0056.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-0056.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-0053.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-0056.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 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-0057.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-0057.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-0057.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-0054.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-0057.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 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-0058.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-0058.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-0058.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-0055.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-0058.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 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-0059.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-0059.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-0059.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-0056.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-0059.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 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-0060.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-0060.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-0060.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-0057.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-0060.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 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-0061.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-0061.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-0061.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-0058.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-0061.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 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-0062.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-0062.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-0062.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-0059.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-0062.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 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-0063.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-0063.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-0063.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-0060.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-0063.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 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-0064.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-0064.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-0064.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-0061.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-0064.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 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-0065.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-0065.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-0065.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-0062.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-0065.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 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-0066.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-0066.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-0066.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-0063.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-0066.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 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-0067.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-0067.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-0067.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-0064.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-0067.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 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-0068.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-0068.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-0068.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-0065.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-0068.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 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-0069.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-0069.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-0069.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-0066.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-0069.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 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-0070.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-0070.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-0070.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-0067.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-0070.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 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-0071.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-0071.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-0071.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-0068.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-0071.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 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-0072.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-0072.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-0072.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-0069.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-0072.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 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-0073.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-0073.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-0073.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-0070.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-0073.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 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-0074.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-0074.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-0074.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-0071.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-0074.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 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-0075.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-0075.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-0075.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-0072.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-0075.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 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-0076.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-0076.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-0076.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-0073.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-0076.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 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-0077.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-0077.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-0077.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-0074.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-0077.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 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-0078.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-0078.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-0078.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-0075.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-0078.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 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-0079.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-0079.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-0079.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-0076.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-0079.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 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-0080.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-0080.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-0080.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-0077.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-0080.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 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-0081.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-0081.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-0081.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-0078.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-0081.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 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-0082.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-0082.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-0082.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-0079.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-0082.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 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-0083.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-0083.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-0083.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-0080.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-0083.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 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-0084.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-0084.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-0084.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-0081.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-0084.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 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-0085.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-0085.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-0085.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-0082.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-0085.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 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-0086.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-0086.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-0086.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-0083.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-0086.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 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-0087.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-0087.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-0087.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-0084.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-0087.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 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-0088.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-0088.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-0088.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-0085.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-0088.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 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-0089.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-0089.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-0089.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-0086.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-0089.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 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-0090.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-0090.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-0090.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-0087.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-0090.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 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-0091.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-0091.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-0091.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-0088.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-0091.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 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-0092.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-0092.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-0092.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-0089.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-0092.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 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-0093.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-0093.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-0093.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-0090.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-0093.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 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-0094.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-0094.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-0094.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-0091.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-0094.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 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-0095.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-0095.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-0095.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-0092.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-0095.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 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-0096.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-0096.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-0096.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-0093.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-0096.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 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-0097.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-0097.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-0097.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-0094.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-0097.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 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-0098.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-0098.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-0098.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-0095.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-0098.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 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-0099.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-0099.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-0099.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-0096.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-0099.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 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-0100.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-0100.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-0100.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-0097.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-0100.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 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-0101.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-0101.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-0101.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-0098.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-0101.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 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-0102.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-0102.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-0102.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-0099.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-0102.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 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-0103.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-0103.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-0103.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-0100.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-0103.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 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-0104.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-0104.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-0104.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-0101.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-0104.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 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-0105.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-0105.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-0105.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-0102.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-0105.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 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-0106.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-0106.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-0106.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-0103.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-0106.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 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-0107.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-0107.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-0107.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-0104.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-0107.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 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-0108.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-0108.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-0108.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-0105.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-0108.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 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-0109.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-0109.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-0109.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-0106.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-0109.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 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-0110.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-0110.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-0110.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-0107.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-0110.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 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-0111.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-0111.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-0111.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-0108.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-0111.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 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-0112.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-0112.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-0112.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-0109.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-0112.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 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-0113.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-0113.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-0113.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-0110.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-0113.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