
On 21:25 Sun 24 Jul , Anatoly Yakovenko wrote:
It's probably out of file descriptors. It's possible that it tries to open another one during the error handling. On Sun, Jul 24, 2016 at 10:50 AM Lana Black
wrote: Hello,
I have run into this RTS bug recently. In short, when executing multiple consequtive forks, after 500-600 or so the process is terminated by SIGSEGV. I know this kind of thing is totally artificial, but still.
The problem I have is that I can't get any meaningful backtrace in gdb. For example, for threaded RTS I get this
(gdb) bt #0 0x0000000000560d63 in base_GHCziEventziThread_ensureIOManagerIsRunning1_info () Backtrace stopped: Cannot access memory at address 0x7fffff7fcea0
For non-threaded RTS I get this
(gdb) bt #0 0x00000000007138c9 in stg_makeStablePtrzh () Backtrace stopped: Cannot access memory at address 0x7fffff7fc720
Build command: ghc --make -O2 -g -fforce-recomp fork.hs Add threaded if needed.
I was able to reproduce this bug with both GHC 7.10.3 and todays HEAD with the code below.
import System.Exit (exitSuccess) import System.Posix.Process (forkProcess)
fork_ n | n > 0 = processPid =<< forkProcess (fork_ $! n - 1) | otherwise = putStrLn "I'm done!"
processPid pid | pid > 0 = exitSuccess | pid < 0 = putStrLn "OOOPS, forkProcess failed!" | otherwise = pure ()
main = fork_ 1000
With best regards. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Seems like this is not the case. I actually overlooked GHCs -debug
option, with it I'm now able to get a stacktrace. Furthermore, the
number of used file descriptors is well within the limit, and changing
the latter with `ulimit -n` does not affect the outcome.
Curiously, the stacks are rather different for threaded and non-threaded
RTS.
Non-threaded:
(gdb) bt
#0 INFO_PTR_TO_STRUCT (info=