[Rxtx] [Patch]?Fix for SIGSEGV at etc

[Trent Jarvi]

The patch will probably go in this weekend along with the release of a new 
set of test binaries.

The release of test binaries is always announced here.


On Wed, 25 Feb 2009, Goldsmith, Noel wrote:

> Hi,
> First, thank you to all of the clever people supporting rxtx, I wish I could
> help, but am still a new  learner (or should that be slow learner) when it
> comes to the intricacies of the serial communication codes.
> Just a simple query.
> The tantalising snippet below tells me that sometime soon a patch will be
> added to the rxtx code, which will make it work even better in multi
> threaded environments, including Mac OS X, which is my particular interest.
> My question is, how do I know when the patch has been applied to the rxtx
> code?
> Is there always an announcement on this list?
> And I am always happy to test the latest rxtx out on G5's and Intel Macs,
> and report back.
> Thank you
> Noel
>
>>
>> Message: 3
>> Date: Mon, 23 Feb 2009 19:23:52 -0700 (MST)
>> From: Trent Jarvi <tjarvi at qbang.org>
>> Subject: Re: [Rxtx] [Patch]?Fix for SIGSEGV at
>> SerialImp.c:interruptEventLoop() on platforms that run drain loop
>> thread
>> To: Ilkka Myller <ilkka at myller.com>
>> Cc: rxtx at qbang.org
>> Message-ID: <alpine.LFD.2.00.0902231921280.11662 at rxtx.qbang.org>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>
>>
>>
>> On Mon, 23 Feb 2009, Ilkka Myller wrote:
>>
>>> Hi everyone,
>>>
>>> My first time posting to this list.. :-)
>>>
>>> I've found a bug in SerialImp.c which causes occasional SIGSEGV halts at
>>> interruptEventLoop().
>>> JVM might halt with "Invalid memory access.." error and exit code 139
>>> (SIGSEGV).
>>> From java side, interruptEventLoop() is eventually called atleast by
>>> RXTXPort.close() and .removeEventListener() methods.
>>>
>>> How often halts happen depends on hardware configuration, usb rs232 adapters,
>>> drivers etc.
>>> This bug only affects platforms that need to run native drain loop thread,
>>> such as Mac OS X (not win/linux).
>>>
>>> Analysis:
>>>
>>> I did some debugging on RXTX native library and found out that following
>>> happens:
>>>
>>> 1. interruptEventLoop() is called
>>> 2. interruptEventLoop() sets eis->eventloop_interrupted = 1
>>> 3. interruptEventLoop() does ptread_kill() on drain loop thread
>>> 4. drain_loop() catches eis->event_loop_interrupted = 1 change, sets
>>> eis->closing=1 and terminates
>>> 5. eventLoop() catches eis->closing=1, and goes to *finalize* eis (as it
>>> should, no problem here)
>>> 6. interruptEventLoop() sleeps ( 50 ms, tcdrain might need time to unblock)
>>> 7. interruptEventLoop() continues, checks eis->closing really is 1 to see if
>>> drain_loop actually died (as it should check, since tcdrain might block drain
>>> loop on some hardware/drivers)
>>>
>>> But.. last step 7 causes obvious SIGSEGV inside if-clause, because eis was
>>> finalized earlier and its contents are therefore undefined.
>>>
>>> By design, steps 4 to 7 run on different simultaneously running threads. As
>>> you can see, depending on the order which steps 5 and 7 take place, SIGSEGV
>>> halt will or will not happen.
>>> Step 5 SHOULD always come last for things to work, but this rarely happens on
>>> some hardware configurations.
>>> On win/linux this issue does not exist, because their implementation of
>>> interruptEventLoop() never uses eis after setting eis->closing=1.
>>>
>>> Proposed fix:
>>>
>>> I've included a patch to fix this issue by adding a new flag to signal
>>> drain_loop() status for interruptEventLoop() (eis->drain_loop_running), while
>>> keeping usage of other eis flags as they were.
>>> Patch removes control of eis->closing flag from drain_loop(), and gives it to
>>> interruptEventLoop(), thus preventing SIGSEGV condition.
>>> I've tried to keep changes to original RXTX code minimal. Also, patch does
>>> not alter the code for "non-drain loop" platforms.
>>>
>>> This patch is against 2.2pre2 and CVS head (@2009/02/21).
>>> I've tested it to work (and resolve the issue) on Mac OS X 10.5.x (both Intel
>>> and PPC).
>>>
>>> Hopefully this patch - or similar addressing this issue - can be integrated
>>> in to final 2.2 release.
>>>
>>
>> Thanks Ilkka
>>
>> I'll spin this on win/linux to make sure its not causing problems here.
>> It should be OK for 2.2.  The solaris/mac path has not been getting as
>> much testing until recently.  I think I want to move to that for all
>> platforms in the future.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>>
>>
>
>
>
>
> IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>