[Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close?
smontgomery at mediaspansoftware.com
Thu Sep 21 05:57:23 MDT 2006
Thanks for the info, Joachim. I'll look for the Bugzilla entry and
add comments if I can come up with a simple case to reproduce it.
Interesting that you've seen it on PPC, I've never seen it myself
there. First time for everything!
On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote:
> I have seen the same kind of crashes as well, albeit on PPC.
> This is due to the fact, that the event_info_struct gets damaged
> during the closing of the port. Which leads to the fact that the
> closing flag gets overwritten by some weird value, which again leads
> to the call to pthread_cancel (normally this should never be called).
> I have posted this some weeks ago, but nobody was able to reproduce
> it. I think I also filed in on Bugzilla.
> Best regard,
> Joachim Büchse
> Softwarelösungen und Beratung
> Hadlaubsteig 2
> CH-8006 Zürich
> On 20.09.2006, at 21:18, Sean Montgomery wrote:
>> I've looked through the mailing list to see if something like this
>> has already been discussed, but I didn't notice anything. Perhaps
>> somebody might have seen something similar.
>> I've got RXTX 2.0.7 final Universal Binary installed on an Intel
>> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X
>> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's
>> their latest Universal Binary drivers).
>> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan
>> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS
>> flowcontrol. I also call enableReceiveTimout(500) so that reads
>> won't block forever. I don't write to the port, I only read.
>> This works fine on all other machines I've tested, PPC and Intel. On
>> this particular box when we attempt to close the serial port the JVM
>> crashes. Here's the appropriate bit of the stack trace:
>> Thread 17 Crashed:
>> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6
>> 1 librxtxSerial.jnilib 0x05fdd18f
>> Java_gnu_io_RXTXPort_interruptEventLoop + 293
>> 2 <<00000000>> 0x03f36c4b 0 + 66284619
>> 3 <<00000000>> 0x03f31bc3 0 + 66264003
>> 4 <<00000000>> 0x03f31bc3 0 + 66264003
>> 5 <<00000000>> 0x03f31bc3 0 + 66264003
>> 6 <<00000000>> 0x03f31bc3 0 + 66264003
>> 7 <<00000000>> 0x03f31bc3 0 + 66264003
>> 8 <<00000000>> 0x03f2f0ed 0 + 66253037
>> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442
>> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424
>> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171
>> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995
>> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726
>> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl +
>> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84
>> So it looks like a 2.0.7 Universal Library on Intel issue. If
>> anybody has any ideas or if closing ports, interrupt event loops and
>> crashes ring any bells, please let me know :-)
>> P.S. The machine in question is several time zones away so I haven't
>> been able to fire the app up in the debugger.
>> Rxtx mailing list
>> Rxtx at qbang.org
> Rxtx mailing list
> Rxtx at qbang.org
More information about the Rxtx