Am 22.03.2016 um 05:52 schrieb denizzzka:
With
settings.options |= HTTPServerOption.distribute;sometimes (after ~3000 requests) server with my own HttpRequestHandler stucks on this state:
(gdb) bt #0 0x00007f27be34c053 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f27bf3d8b08 in ?? () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 #2 0x00007f27bf3c3d5a in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 #3 0x00000000007ee099 in vibe.core.drivers.libevent2.Libevent2Driver.runEventLoop() (this=0x7f27c017b600) at ../vibe.d/source/vibe/core/drivers/libevent2.d:196 #4 0x00000000007ea1b0 in vibe.core.core.runEventLoop() () at ../vibe.d/source/vibe/core/core.d:99 #5 0x000000000070e130 in pgator.app.loop() (methods=..., client=0x7f27c018aec0, cfg=...) at source/app.d:233 #6 0x000000000070de3a in D main (args=...) at source/app.d:135 #7 0x00000000008abbd7 in rt.dmain2._d_run_main() () #8 0x00000000008abb15 in rt.dmain2._d_run_main() () #9 0x00000000008abb93 in rt.dmain2._d_run_main() () #10 0x00000000008abb15 in rt.dmain2._d_run_main() () #11 0x00000000008aba72 in _d_run_main () #12 0x0000000000713b80 in main () (gdb)What could be a reasons? There is a ways to debug this?
The stack trace looks good so far (the usual wait for new events). Do
the other threads have a similar trace? The best bet to find where a
task hangs is currently to set the log level to LogLevel.trace (or run
with --vvvv). If that doesn't help, setting a task event callback and
logging from there would be a possibility.
I started to create a graphical debugger especially for vibe.d's task
model a while ago, but didn't work on it since then. I'll have to pick
that back up one day, as that would greatly simplify debugging such issues.