[Soot-list] Race condition in Heros

[Marc-Andre Laverdiere-Papineau]

Hi Eric,

You have a pull request waiting for you with a fix :)

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 13-01-25 08:43 AM, Eric Bodden wrote:
> ... and another possible solution seem to be semaphores:
> http://stackoverflow.com/questions/6585337/calling-object-notify-before-object-wait
>
> Eric
>
> On 25 January 2013 14:42, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>> Hi again.
>>
>> It just occurred to me... I think the problem can only occur if
>> notify() happens before the wait(). Unfortunately, that's something
>> that's hard to control. Hence I wonder whether one should not just
>> give a timeout to the wait(..) call, say, one second or so. That would
>> cause the loop to wrap around at least once a second and should allow
>> normal termination that way.
>>
>> Eric
>>
>> On 25 January 2013 14:39, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>>> Hello.
>>>
>>>> It is a deadlock, actually. Most times, the analysis is over in a few
>>>> minutes. In other times, it doesn't complete in >15 minutes, and my CPU
>>>> usage is down. I infer from this that the analysis completed, but there
>>>> was a race condition between the notify and the wait that make it so
>>>> that wait never returns.
>>>
>>> Oh, I see.
>>>
>>>> Having worked with ExecutorService, the trick that I used was to load
>>>> the executor up front with all the work units that needed to be treated,
>>>> then call shutdown(), which will allow the backlog to be processed, then
>>>> loop around awaitTermination().
>>>>
>>>> Obviously, that works only when you know for sure that you won't have
>>>> more work units. I think the solver code I see there assumes that an
>>>> empty worklist will stay empty, so that trick will work.
>>>
>>> No, if the worklist is empty it may still be the case that tasks are
>>> running that place items into the worklist again. That's why there's
>>> the check numTasks.intValue()==0 before the return statement.
>>>
>>>> IIRC, I needed to change the default queue, because the standard Java
>>>> API was giving one with a bound in the number of jobs it would accept.
>>>>
>>>> You would have to use the constructor of the ThreadPoolExecutor instead
>>>> of the convenience methods in Executors.
>>>
>>> I am not quite sure how that would avoid a deadlock, though.
>>>
>>>> P.S. I get this feeling that I've almost written the code here ;) I may
>>>> have a bit of time later to work on a patch.
>>>
>>> Ok, thanks!
>>>
>>> Cheers,
>>> Eric
>>
>>
>>
>> --
>> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
>> Head of Secure Software Engineering Group at EC SPRIDE
>> Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>
>
>