<div dir="ltr">Ok, I will file an issue. I just wanted to rule out any application level issues first. Did you try it on the code I sent or did you use some other test case? Is there a test-suite in GHC that stresses the threaded runtime?<div><br></div><div>-harendra</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 Feb 2020 at 14:09, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In that case it'd be good to move the discussion to Gitlab. Could you file an<br>
issue?<br>
<br>
I was able to reproduce on GHC HEAD. With debug runtime I consistently get this<br>
assertion error:<br>
<br>
    internal error: ASSERTION FAILED: file rts/Messages.c, line 95<br>
<br>
        (GHC version 8.11.0.20200201 for x86_64_unknown_linux)<br>
        Please report this as a GHC bug:  <a href="https://www.haskell.org/ghc/reportabug" rel="noreferrer" target="_blank">https://www.haskell.org/ghc/reportabug</a><br>
<br>
In non-debug runtime it works fine maybe half of the time, in others I get a<br>
panic in the GC.<br>
<br>
Ömer<br>
<br>
Harendra Kumar <<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.com</a>>, 3 Şub 2020 Pzt, 10:01<br>
tarihinde şunu yazdı:<br>
><br>
> Unfortunately, it is present in 8.8.2 as well.<br>
><br>
> On Mon, 3 Feb 2020 at 11:22, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>> wrote:<br>
>><br>
>> You should try with 8.8.2 which fixes a bug in the compacting GC (#17088).<br>
>><br>
>> When debugging it's a good idea to use the latest minor release of your GHC<br>
>> version (8.8.2 in your case), as minor releases fix bugs and usually do not<br>
>> introduce new ones as they don't ship new features.<br>
>><br>
>> If the problem still exists, unless you're interested in GHC hacking I think<br>
>> most productive use of the time would be to make the reproduer smaller, and<br>
>> collect as many data as possible, like which flags trigger/hide the bug.<br>
>><br>
>> Some of the things you could check:<br>
>><br>
>> - Build your program with `-dcore-lint -dstg-lint -dcmm-lint` and see if it<br>
>>   builds.<br>
>> - Build your program with `-debug` and run it, see if it crahes.<br>
>> - Build your program with `-debug` and run it with `+RTS -DS` and see if the<br>
>>   error message changes.<br>
>><br>
>> But really you should try with 8.8.2 as first thing. It's possible that this is<br>
>> another manifestation of #17088.<br>
>><br>
>> Ömer<br>
>><br>
>> Harendra Kumar <<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.com</a>>, 3 Şub 2020 Pzt, 01:26<br>
>> tarihinde şunu yazdı:<br>
>> ><br>
>> > Hi,<br>
>> ><br>
>> > While running a test-suite for the streaming library streamly I am encountering a crash which seems to happen at random places at different times. The common messages are:<br>
>> ><br>
>> > * Segmentation fault: 11<br>
>> > *  internal error: scavenge_mark_stack: unimplemented/strange closure type 24792696 @ 0x4200a623e0<br>
>> > * internal error: update_fwd: unknown/strange object  223743520<br>
>> ><br>
>> > and several other such messages. Prima facie this looks like the memory is getting corrupted/scribbled somehow. My first suspicion was that this could be a problem in the streamly library code. But I have stripped down the code to bare minimum and there is no C FFI code or no poking to memory pointers.<br>
>> ><br>
>> > My next suspicion was the hspec/quickcheck testing code that is being used in this test. I checked the hspec code to ensure that there is no C code/pointer poking in any of the code involved. But no luck there as well, still looking to further strip down that code.<br>
>> ><br>
>> > My suspicion now is moving more towards the GHC RTS. This issue only shows when the following conditions are met:<br>
>> ><br>
>> > * hspec "parallel" combinator is used to run tests in parallel<br>
>> > * streamly concurrent code is being tested which can create many threads<br>
>> > * The GHC heap size is restricted to a small size ~32MB using "-M32M" rts option.<br>
>> > * It is consistently seen with GHC 8.6.5 as well as GHC 8.8.1<br>
>> ><br>
>> > It never occurs when the heap size is not restricted. I have seen random crashes before as well with a "IO manager die" message, when using concurrent networking IO with streamly. Though earlier it was not easily reproducible, I stopped chasing it. But now it looks like that issue might also be a manifestation of the same underlying problem.<br>
>> ><br>
>> > My guess is it could be something in the RTS concurrency/threading related code. Let me know if the symptoms ring a bell or if you can point to something specific based on the symptoms. Also, what are the usual tools/methods/debugging aids/flags to debug such issues in GHC? If not a GHC issue what are the possible ways in which such problem can be induced by application code?<br>
>> ><br>
>> > Meanwhile, I am also trying to simplify the reproducing code further to remove other factors as much as possible. The current code is at <a href="https://github.com/composewell/streamly" rel="noreferrer" target="_blank">https://github.com/composewell/streamly</a> on the ghc-segfault branch. Run "$ while true; do cabal run properties || break; done" in the shell and if you are lucky it may crash soon. The test code is in "test/Prop.hs" - here <a href="https://github.com/composewell/streamly/blob/ghc-segfault/test/Prop.hs" rel="noreferrer" target="_blank">https://github.com/composewell/streamly/blob/ghc-segfault/test/Prop.hs</a> .<br>
>> ><br>
>> > -harendra<br>
>> > _______________________________________________<br>
>> > ghc-devs mailing list<br>
>> > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>