#5085: internal error: evacuate: strange closure type
-----------------------------+----------------------------------------------
Reporter: mitar | Owner: simonmar
Type: bug | Status: closed
Priority: highest | Milestone: 7.4.1
Component: Runtime System | Version: 7.1
Resolution: wontfix | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty:
Testcase: | Blockedby:
Blocking: | Related:
-----------------------------+----------------------------------------------
Comment(by mitar):
That's interesting. I tried to reproduce this on a virtual machine running
Linux and I tried 7.0.4, 7.2.2 and 7.4.1 and I cannot reproduce it
anymore. It is true that I kept the same Haskell platform (2012.2) for all
tests. That is probably a good thing.
But what is even more interesting is that my algorithm does not work
correctly on 7.2.2 and 7.4.1 anymore! It is a message-passing shortest-
path searching algorithm which incrementally updates states of each node
as it discovers better and better paths. And when it finds a better node,
it informs all the neighbors about that which might also improve their
list of best paths. And this is repeated. Every node is a Haskell spark,
edges, too. So I really create a lot of sparks. At least around 60000 of
them for `-s 400`. :-)
And on 7.0.4 algorithm works. When messages stop being passed around, all
shortest paths are found. But on 7.2.2 and 7.4.1 this is not so. Again and
again only around 91% paths are found and then messages stop and program
finishes because of this, but not all paths are found.
I am not working on this project anymore so I also don't have time or
motivation to really debug it. I just wanted to publish my findings. So
something is different between 7.0 and 7.2+ versions. Maybe there is a bug
in my code which was not visible before. Maybe some API semantic changed
just slightly, so that GHC sill compiles, but behavior is changed. I don't
know. And it is too complex and stochastic to easy debug it. But of
course, this is also why it is a good example of a complex program which
really pushes GHC and its runtime to limits.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5085#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
