Deadlock in S4A 3.0

[Google Code Exporter]

What's the problem?
When running IsisTestsuite you can produce a deadlock in the service.

What steps will reproduce the problem?
1. Run IsisTestSuite a number of times.

What is the expected output? What do you see instead?
Deadlock

What version of the product are you using? On what operating system?
3.0

Please provide any additional information below.

transmit()deadlocks with openLogicalChannel()

Solution:
Move synchronization on mLock into synchronized method protocolTransmit()
That was protocolTransmit will not lock mLock without getting access to 
UiccTerminal.

See attached file for fix.

Original issue reported on code.google.com by [e-mail] on 13 Jun 2013 at 2:32

Attachments:

• Terminal.java

[Google Code Exporter]

The reporter seems to have reported an issue that can/should be fixed in the 
common code than the OEM adaptation layer.  However, reporter didn't really 
give a good explanation on the root cause analysis and what exact situation 
(multiple threads/multiple process) and the most simplify steps that leads to 
the issue.

Would the reporter please elaborate and clarify a bit more about the root cause 
and why this solution? 

Original comment by [e-mail] on 13 Jun 2013 at 7:59

[Google Code Exporter]

Hi,

I don't know if I can make the steps easier. Run Isis Testsuite 1.3.2 a number 
of times. OM w/ permission, APDU section. By running it a couple of times in a 
row, it should be trigggered - but of course it is timing sensitive. 

The reason it happens is a race condition between two locks. Some methods are 
synchronized and some use synchronized object lock.

A.
transmit(...) locks on mLock
protocolTransmit(...) is synchronized on UiccTerminal


B.
AraController.initialize is synchronized method on UiccTerminal
[... calls]
Terminal.openLogicalChannel() which tries to aquire mLock.

1 A. starts with taking mLock in transmit()
2 B. has/takes UiccTerminal
3 A. has mLock and waits UiccTerminal to execute protocolTransmit(...) 
4 B. has UiccTerminal and waits for mLock to execute openLogicalChannel(...)

--
I just moved the mLock aquirement into protocolTransmit. That ensures that A. 
gets the UiccTerminal lock before it requests the mLock, thereby avoiding the 
race-condition.

Hope this is more clear.

Original comment by [e-mail] on 14 Jun 2013 at 7:36

[Google Code Exporter]

other than the first paragraph being confusing, the info given afterward seems 
to help illustrate the situation and the root issue of the code.  is that 
enough info for SEEK to accept the error and provide a patch?

Original comment by [e-mail] on 14 Jun 2013 at 3:18

[Google Code Exporter]

Thx Mats!

Patch for SCAPI-3.0.0 that includes the proposed change. Further SEEK updates 
will include the patch.

Can someone verify & close?

Original comment by [e-mail] on 5 Jul 2013 at 2:29

• Changed state: Fixed

Attachments:

• issues_59.patch