[Soot-list] Race condition in Heros

[Eric Bodden]

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