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 <[email protected]> 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 <[email protected]>, 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 <[email protected]> > 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 <[email protected]>, 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 > >> > [email protected] > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
