> Did you try it on the code I sent or did you use some other test case?
I tried your code. It's still possible that this is an application bug, of course (maybe in one of the dependencies, if not in your application). > Is there a test-suite in GHC that stresses the threaded runtime? Some of the tests in the test suite uses threaded runtime. Other than those not really. Ömer Harendra Kumar <harendra.ku...@gmail.com>, 3 Şub 2020 Pzt, 12:29 tarihinde şunu yazdı: > > 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? > > -harendra > > On Mon, 3 Feb 2020 at 14:09, Ömer Sinan Ağacan <omeraga...@gmail.com> wrote: >> >> In that case it'd be good to move the discussion to Gitlab. Could you file an >> issue? >> >> I was able to reproduce on GHC HEAD. With debug runtime I consistently get >> this >> assertion error: >> >> internal error: ASSERTION FAILED: file rts/Messages.c, line 95 >> >> (GHC version 8.11.0.20200201 for x86_64_unknown_linux) >> Please report this as a GHC bug: >> https://www.haskell.org/ghc/reportabug >> >> In non-debug runtime it works fine maybe half of the time, in others I get a >> panic in the GC. >> >> Ömer >> >> Harendra Kumar <harendra.ku...@gmail.com>, 3 Şub 2020 Pzt, 10:01 >> tarihinde şunu yazdı: >> > >> > Unfortunately, it is present in 8.8.2 as well. >> > >> > On Mon, 3 Feb 2020 at 11:22, Ömer Sinan Ağacan <omeraga...@gmail.com> >> > wrote: >> >> >> >> You should try with 8.8.2 which fixes a bug in the compacting GC (#17088). >> >> >> >> When debugging it's a good idea to use the latest minor release of your >> >> GHC >> >> version (8.8.2 in your case), as minor releases fix bugs and usually do >> >> not >> >> introduce new ones as they don't ship new features. >> >> >> >> If the problem still exists, unless you're interested in GHC hacking I >> >> think >> >> most productive use of the time would be to make the reproduer smaller, >> >> and >> >> collect as many data as possible, like which flags trigger/hide the bug. >> >> >> >> Some of the things you could check: >> >> >> >> - Build your program with `-dcore-lint -dstg-lint -dcmm-lint` and see if >> >> it >> >> builds. >> >> - Build your program with `-debug` and run it, see if it crahes. >> >> - Build your program with `-debug` and run it with `+RTS -DS` and see if >> >> the >> >> error message changes. >> >> >> >> But really you should try with 8.8.2 as first thing. It's possible that >> >> this is >> >> another manifestation of #17088. >> >> >> >> Ömer >> >> >> >> Harendra Kumar <harendra.ku...@gmail.com>, 3 Şub 2020 Pzt, 01:26 >> >> tarihinde şunu yazdı: >> >> > >> >> > Hi, >> >> > >> >> > 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: >> >> > >> >> > * Segmentation fault: 11 >> >> > * internal error: scavenge_mark_stack: unimplemented/strange closure >> >> > type 24792696 @ 0x4200a623e0 >> >> > * internal error: update_fwd: unknown/strange object 223743520 >> >> > >> >> > 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. >> >> > >> >> > 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. >> >> > >> >> > My suspicion now is moving more towards the GHC RTS. This issue only >> >> > shows when the following conditions are met: >> >> > >> >> > * hspec "parallel" combinator is used to run tests in parallel >> >> > * streamly concurrent code is being tested which can create many threads >> >> > * The GHC heap size is restricted to a small size ~32MB using "-M32M" >> >> > rts option. >> >> > * It is consistently seen with GHC 8.6.5 as well as GHC 8.8.1 >> >> > >> >> > 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. >> >> > >> >> > 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? >> >> > >> >> > Meanwhile, I am also trying to simplify the reproducing code further to >> >> > remove other factors as much as possible. The current code is at >> >> > https://github.com/composewell/streamly 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 >> >> > https://github.com/composewell/streamly/blob/ghc-segfault/test/Prop.hs . >> >> > >> >> > -harendra >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs@haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
