Re: Thank you for trying out SWISH - here are the bugs

Hi Torbjörn,

Pushed a fix.  That seems to fix the termination issue, but some stress
testing indicates there are still other problems with this code.  They
might not affect your real case.  One seems a race condition if the
thread_get_message kicks in before the thread is started.  The other,
which I saw only once, seems a an issue in stream handling.  Will look
at these later.  For now, you should be fine.

That said, peeking in someone else's input queue is ugly.  I things
get cleaner if you use a separate queue for the communication.

	Cheers --- Jan


On 07/21/2013 03:31 PM, Torbjörn Lager wrote:
> Hi again Jan,
> 
> Here's a goal that triggers a failed assertion:
> 
> ?- thread_create((repeat, fail), Id, [detached(true)]),
> thread_create(thread_get_message(Id, A),_,[]), thread_signal(Id,
> abort).
> 
> Hope that can be fixed!
> 
> Best,
> Torbjörn
> 
> On Sat, Jul 20, 2013 at 9:42 AM, Jan Wielemaker <[email protected]> wrote:
>> Hi Torbjörn,
>>
>> Good to see it attracts attention!
>>
>> Destroying message queues is supposed to be safe at all times.  This
>> is a bug.  Only, I need something to reproduce it, or at least a core
>> dump in which I can poke around to examine the state of the system.
>>
>> (to do that, compile for debugging as indicated in build, enable core
>> dumps using "ulimit -c unlimited" and provide me with a login).
>>
>>         --- Jan
>>
>> On 07/20/2013 09:36 AM, Torbjörn Lager wrote:
>>> Hi All,
>>>
>>> Thanks to all of you who played with SWISH. The test release went well
>>> I think, since only two bugs unknown to me has surfaced so far.
>>> Norbert Fuchs found that when saving a program containing "\+" the
>>> +-sign disappeared. Likely an encoding issue. Will fix it tomorrow or
>>> on Monday.
>>>
>>> A more serios bug is related to the ending of sessions. Three times
>>> last night the server crashed with the following message:
>>>
>>> [Thread 19] pl-thread.c:2899: destroy_message_queue: Assertion failed:
>>> !queue->waiting && !queue->wait_for_drain
>>> Stack trace labeled "crash":
>>>   [0] swipl() [0x80eea93]
>>>   [1] swipl() [0x80bcf0a]
>>>   [2] swipl() [0x80bf0df]
>>>   [3] swipl() [0x80c0b57]
>>>   [4] swipl() [0x80c1d4b]
>>>   [5] /lib/i686/cmov/libpthread.so.0(+0x5955) [0xb763b955]
>>>   [6] /lib/i686/cmov/libc.so.6(clone+0x5e) [0xb75bbe7e]
>>> Aborted
>>>
>>> I *think* that this occured when a session timed out (after ten
>>> minutes of inactivity) and was supposed to clean up a few resources.
>>> The relevant code is here:
>>>
>>> %   When a client session ends, the currently running goal (if any)
>>> %   is aborted, the output queue is destroyed, and the client module
>>> %   is emptied.
>>>
>>> :- listen(http_session(end(SessionId, _Peer)), end_session(SessionId)).
>>>
>>> end_session(SessionId) :-
>>>     catch(thread_signal(SessionId, abort), _, true),
>>>     atom_concat(SessionId, '.out', Output),
>>>     message_queue_destroy(Output),
>>>     forall(current_predicate(SessionId:PI),
>>>         (   memberchk(PI, [read/1, write/1, writeln/1, nl/0])
>>>         ->  true
>>>         ;   abolish(SessionId:PI)
>>>         )
>>>     ).
>>>
>>> The message queue is created when the session begins and as far as I
>>> can see it should be possible to destroy it in this way. Maybe you can
>>> spot the problem?
>>>
>>> I will have to return to this on Monday. I will leave the server
>>> running, but I guess it is likely to crash again and then I won't be
>>> here to restart it.
>>>
>>> Best,
>>> Torbjörn
>>>
>>> --
>>> Torbjörn Lager
>>> Professor of General and Computational Linguistics
>>> Department of Philosophy, Linguistics and Theory of Science
>>> University of Gothenburg
>>> Box 200, SE-405 30 Gothenburg, Sweden
>>> Phone: +46317864962
>>> _______________________________________________
>>> SWI-Prolog mailing list
>>> [email protected]
>>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>>>
> 
> 
>