flamethrower icon indicating copy to clipboard operation
flamethrower copied to clipboard

numberqname generator error handling is confusing

Open pemensik opened this issue 1 year ago • 6 comments

# flame -P tcp -g numberqname -r test. 127.0.0.2
binding to 0.0.0.0
flaming target(s) [127.0.0.2] on port 53 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol tcp
query generator [numberqname] contains 0 record(s)
terminate called after throwing an instance of 'std::runtime_error'
  what():  tcp unsupported
Aborted (core dumped)
# rpm -q flamethrower
flamethrower-0.11.0-12.fc37.x86_64

Is something wrong with my build or flamethrower indeed cannot measure TCP, but can measure dot from the same binary?

pemensik avatar Jun 09 '23 14:06 pemensik

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007f8b782afec3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f8b7825fa76 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007f8b782497fc in __GI_abort () at abort.c:79
#4  0x00007f8b784a2b37 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#5  0x00007f8b784ae44c in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#6  0x00007f8b784ad4b9 in __cxa_call_terminate (ue_header=0x55c0173b76f0) at ../../../../libstdc++-v3/libsupc++/eh_call.cc:54
#7  0x00007f8b784adbd6 in __cxxabiv1::__gxx_personality_v0 (version=<optimized out>, actions=6, exception_class=5138137972254386944, 
    ue_header=<optimized out>, context=0x7ffe86bbfbd0) at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:688
#8  0x00007f8b787d0894 in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x55c0173b76f0, context=context@entry=0x7ffe86bbfbd0, 
    frames_p=frames_p@entry=0x7ffe86bbfad8) at ../../../libgcc/unwind.inc:64
#9  0x00007f8b787d12ed in _Unwind_Resume (exc=exc@entry=0x55c0173b76f0) at ../../../libgcc/unwind.inc:242
#10 0x00007f8b7887a955 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=<optimized out>, this=<optimized out>)
    at /usr/include/c++/12/bits/shared_ptr_base.h:1071
#11 std::__shared_ptr<uvw::details::ConnectReq, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=<optimized out>, this=<optimized out>)
    at /usr/include/c++/12/bits/shared_ptr_base.h:1524
#12 std::shared_ptr<uvw::details::ConnectReq>::~shared_ptr (this=<optimized out>, this=<optimized out>)
    at /usr/include/c++/12/bits/shared_ptr.h:175
#13 uvw::Request<uvw::details::ConnectReq, uv_connect_s>::defaultCallback<uvw::ConnectEvent> (req=<optimized out>, 
    status=<optimized out>) at /usr/include/uvw/request.hpp:34
#14 0x00007f8b7884ce87 in uv__stream_connect (stream=0x55c01733ccd8) at src/unix/stream.c:1345
#15 uv__stream_io (loop=<optimized out>, w=0x55c01733cd60, events=4) at src/unix/stream.c:1262
#16 0x00007f8b788517cd in uv__io_poll (loop=0x7f8b7885d160 <default_loop_struct>, timeout=<optimized out>) at src/unix/epoll.c:374
#17 0x00007f8b7883b72a in uv__io_poll (timeout=<optimized out>, loop=0x7f8b7885d160 <default_loop_struct>) at src/unix/udp.c:122
#18 uv_run (loop=0x7f8b7885d160 <default_loop_struct>, mode=UV_RUN_DEFAULT) at src/unix/core.c:406
#19 0x000055c01642e47a in uvw::Loop::run<(uvw::details::UVRunMode)0> (this=0x55c017321910) at /usr/include/uvw/loop.cpp:72
#20 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/flamethrower-0.11.0-12.fc37.x86_64/flame/main.cpp:509

Built with libuv-1.44.2-2.fc37.x86_64.

pemensik avatar Jun 09 '23 14:06 pemensik

TCP is supported - something must not be building right

weyrick avatar Jun 09 '23 20:06 weyrick

Not sure why that happens. If I choose server on address where is nothing listening, it starts.

But not when there is something listening.

binding to 0.0.0.0                                                                                                                      
flaming target(s) [127.0.0.1] on port 53 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol tcp
query generator [numberqname] contains 0 record(s)
terminate called after throwing an instance of 'std::runtime_error'
  what():  tcp unsupported

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file /usr/src/debug/glibc-2.37-4.fc38.x86_64/nptl/pthread_kill.c
44            return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;                                                 
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff76b08b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff765fabe in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff764887f in __GI_abort () at abort.c:79
#4  0x00007ffff78a4cf9 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#5  0x00007ffff78b4f6c in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#6  0x00007ffff78b3fe9 in __cxa_call_terminate (ue_header=0x61e820) at ../../../../libstdc++-v3/libsupc++/eh_call.cc:54
#7  0x00007ffff78b46f6 in __cxxabiv1::__gxx_personality_v0 (version=<optimized out>, actions=6, exception_class=5138137972254386944, 
    ue_header=<optimized out>, context=0x7fffffff9040) at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:688
#8  0x00007ffff7ef5aa9 in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x61e820, context=context@entry=0x7fffffff9040, 
    frames_p=frames_p@entry=0x7fffffff8f48) at ../../../libgcc/unwind.inc:64
#9  0x00007ffff7ef659d in _Unwind_Resume (exc=0x61e820) at ../../../libgcc/unwind.inc:242
#10 0x00000000004ad2ba in uvw::Request<uvw::details::ConnectReq, uv_connect_s>::defaultCallback<uvw::ConnectEvent> (req=0x5a38e8, 
    status=0) at /home/pemensik/upstream/flamethrower/3rd/uvw/uvw/request.hpp:28
#11 0x00007ffff7f91ca7 in uv__stream_connect (stream=0x59ce10) at src/unix/stream.c:1345
#12 uv__stream_io (loop=<optimized out>, w=0x59ce98, events=4) at src/unix/stream.c:1262
#13 0x00007ffff7f96873 in uv__io_poll (loop=0x7ffff7fa1160 <default_loop_struct>, timeout=<optimized out>) at src/unix/epoll.c:374
#14 0x00007ffff7f7f60a in uv__io_poll (timeout=<optimized out>, loop=0x7ffff7fa1160 <default_loop_struct>) at src/unix/udp.c:122
#15 uv_run (loop=0x7ffff7fa1160 <default_loop_struct>, mode=UV_RUN_DEFAULT) at src/unix/core.c:406
#16 0x0000000000467abb in uvw::Loop::run<(uvw::details::UVRunMode)0> (this=0x5a1f30)
    at /home/pemensik/upstream/flamethrower/3rd/uvw/uvw/loop.hpp:307
#17 0x0000000000460c67 in main (argc=8, argv=0x7fffffffddc8) at /home/pemensik/upstream/flamethrower/flame/main.cpp:503

But running on not-responding target starts fine.

$ ./flame -P tcp -g numberqname -r test. 127.0.0.2
binding to 0.0.0.0
flaming target(s) [127.0.0.2] on port 53 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol tcp
query generator [numberqname] contains 0 record(s)
0.789971s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
1.79071s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
2.79089s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0
^C3.29046s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/-nan/0ms, in flight: 0, timeouts: 0

------
run id      : 7fffcd6820f0
run start   : 2023-06-09T22:52:29Z
runtime     : 3.2922 s
total sent  : 0
total rcvd  : 0
min resp    : 0 ms
avg resp    : -nan ms
max resp    : 0 ms
avg r qps   : 0
avg s qps   : 0
avg pkt     : 0 bytes
tcp conn.   : 0
timeouts    : 0 (-nan%) 
bad recv    : 0
net errors  : 0

Trying tag v0.11.0 with Compile under gcc 12.0.0

pemensik avatar Jun 09 '23 22:06 pemensik

That's a red herring. The error message is confusing but the source of the problem is misconfiguration.

Try flame -P tcp -g "numberqname low=0 high=2" -r test. 127.0.0.2 (note the ").

pspacek avatar Jan 11 '24 10:01 pspacek

Oh, interesting. Both flame -P tcp -g "numberqname low=0 high=2" -r test. 127.0.0.2 and flame -P tcp -g "numberqname low=0 high=2" -r test. 127.0.0.1 with unbound running locally pass just fine and the latter actually measuring something.

Does that mean we are lacking some smart defaults for numberqname and report it by crashing?

pemensik avatar Jan 12 '24 16:01 pemensik

Interesting. Even specification what should be already be default does make it working well: flame -P tcp -g "numberqname low=0" -r test. 127.0.0.1 works nicely. According to man flame low should default to 0 already, so it should behave exactly the same way as if it were missing. But it is different for some reason.

Tested version: flamethrower-0.11.0-24.fc38.x86_64

pemensik avatar Jan 12 '24 16:01 pemensik