[Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close?

[Sean Montgomery]

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!

- Sean

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
>
>
> ---
> 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 +  
>> 34773
>> 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 :-)
>>
>> Thanks,
>>
>> Sean
>>
>> 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
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx