Possible bug related to stm and exceptions

[Andreas Voellmy]

Thanks! I'll try to reduce my test case and then I'll post an issue.

I'm currently suspecting that it has something to do with signal handling
and STM. It seems that the program goes wrong after getting a SIGPIPE from
trying to send to a closed socket.


On Thu, Oct 17, 2013 at 9:35 AM, Ryan Yates <fryguybob at gmail.com> wrote:

> The bug that Luite and I uncovered is
> http://ghc.haskell.org/trac/ghc/ticket/7930.  It would not be related.
>  There was a bug relating to `catchSTM` that was fixed recently:
> http://ghc.haskell.org/trac/ghc/ticket/8035.  And another related to
> profiling: http://ghc.haskell.org/trac/ghc/ticket/8298.  I doubt either
> of these is related.  I'm happy to help narrow things down.
>
> Ryan
>
>
> On Thu, Oct 17, 2013 at 4:39 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> On 17/10/2013 03:01, Andreas Voellmy wrote:
>>
>>> Hi all,
>>>
>>> I have a program that uses STM heavily and also performs lots of foreign
>>> calls. I've noticed that sometimes the program uses 100% CPU
>>> indefinitely and uses lots of memory - I see it go up to about 5GB
>>> before I kill it. I've grabbed some preliminary samples of stack traces
>>> and see lots stm related stuff (e.g. lots of stg_atomically_frame_info
>>> and stmCommitTransaction entries).  I can pretty reliably get the
>>> behavior to happen now by closing a socket that my Haskell program is
>>> trying to recv from. When this causes an exception to be raised
>>> (something like "recv: resource vanished (Connection reset by peer)") ,
>>> then this behavior gets triggered.  I haven't pinned down the bug yet,
>>> but I'm suspecting it is STM related - somehow the exception causes some
>>> STM transaction to go wrong.
>>>
>>> Are there any known bugs that sound similar to this?
>>>
>>> BTW, this is with GHC 7.6.3 from a recent HP release on OS X.
>>>
>>
>> Please create a ticket and dump all the information you have in it. There
>> might be something we can tell from the stack trace, but if not we'll need
>> a way to reproduce it.
>>
>> Cheers,
>> Simon
>>
>>
>> ______________________________**_________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131017/22b43397/attachment.html>