Hello Kazu, My original intent was to accept different kinds of traffic on the same port. Then I wanted to figure out what protocol is used by analyzing first few received bytes and if that's HTTP, pass it to Warp. So I used internal runSettingsConnection to continue processing after connection has already been established. Current "warp-ghc-issue" repository doesn't have all the protocol detection machinery and all that it does is simply accepting socket and passing it to runSettingsConnection. At the first glance it seems fully legitimate, but triggers behavior described. I have studied Warp source code to figure out what could possibly go wrong, but currently it just looks to me that I do almost exactly the same things as public Network.Wai.Handler.Warp.run function (except for async exceptions handling, supporting TLS and other features). I don't see how could I trigger an infinite loop (although I admit that something goes very wrong with my code and doesn't go wrong with Warp's run function). Even if that's an infinite loop - why does it crash instead of just looping? Do you think I should create an issue at Warp's bug tracker? Regards, Anton. 02.03.2016 6:59, Kazu Yamamoto (山本和彦) пишет:
Hi,
repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137
(GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) I can reproduce this on my 64bit Mac.
But the code in https://github.com/anton-dessiatov/warp-ghc-issue is very starange to me. Why do you use interal APIs such as socketConnection runSettingsConnection? Why don't you use normal APIs such as runSettingsSocket?
I guess your usage of the internal APIs triggers an infinite loop.
--Kazu