Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

numberqname generator error handling is confusing #104

Open
pemensik opened this issue Jun 9, 2023 · 6 comments
Open

numberqname generator error handling is confusing #104

pemensik opened this issue Jun 9, 2023 · 6 comments

Comments

@pemensik
Copy link
Contributor

pemensik commented Jun 9, 2023 

# 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
Copy link
Contributor Author

pemensik commented Jun 9, 2023 

(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.

@weyrick
Copy link
Contributor

weyrick commented Jun 9, 2023

TCP is supported - something must not be building right

@pemensik
Copy link
Contributor Author

pemensik commented Jun 9, 2023

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

@pspacek
Copy link
Collaborator

pspacek commented Jan 11, 2024 •
edited

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 ").

@pemensik
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@pspacek pspacek changed the title Is TCP support completely missing? numberqname generator error handling is confusing Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@weyrick @pspacek @pemensik