A bug of multicore IO manager

Andreas Voellmy andreas.voellmy at gmail.com
Wed Sep 4 00:58:59 CEST 2013


Hi Kazu,

What sort of workload was the mighty server under during those 1 or 2 days
while you waited for it to become unresponsive. I.e. was this a production
web server? Or were you generating requests at some frequency or leaving it
mostly idle?

-Andi


On Tue, Sep 3, 2013 at 6:29 PM, Andreas Voellmy
<andreas.voellmy at gmail.com>wrote:

> Kazu, thanks for noticing this! I will try to recreate it on my server as
> well.
>
> -Andi
>
>
> On Tue, Sep 3, 2013 at 5:57 PM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> Hi Kazu,
>>
>> On Tue, Sep 3, 2013 at 2:52 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>>
>>> Hi,
>>>
>>> As I said before, I started running HTTP server using Mio in the real
>>> world. Unfortunately, the daemon is not stable.
>>>
>>> After one day or so, the server cannot accept any HTTP requests.  No
>>> error messages from the server.
>>>
>>> The server is alive. To terminate the server (running in a "screen"
>>> terminal), single Ctrl-c is not enough. Typing Ctrl-c again terminates
>>> the server.
>>>
>>
>> Could you run an strace on the process in this state so we can get an
>> idea what it's doing?
>>
>>
>>> After several tests, I'm getting convinced that this occurs only when
>>> +RTS -N<x> is specified (where <x> >= 2). The server runs well if +RTS
>>> -N<x> is not specified.
>>>
>>
>> That indicates that the problem is with the threaded RTS and perhaps with
>> the IO manager.
>>
>>
>>> My question: if the program complied with GHC needs double Ctrl-c to
>>> terminate, what is the situation of the program?
>>>
>>
>> If Ctrl+C generates an exception (does it?) there could be an overzealous
>> exception catcher somewhere that catches all exceptions, including your
>> Ctrl+C.
>>
>>
>>>
>>> P.S.
>>>
>>> It seems to me that the server also is leaking space. The server is
>>> getting fatter gradually.
>>
>>
>> Could you use the profiler to see what type of objects are leaking?
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130903/14d48d1a/attachment.htm>


More information about the ghc-devs mailing list