You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the request created by a getdns_general call invoces the callbackfn with GETDNS_CALLBACK_TIMEOUT then calling of getdns_context_destroy immediately after the event_base_loop crashes. The sample code is at gitlab. Schematically:
Getdns (Ubuntu 20.04; getdns branch develop) is configured with -DENABLE_UNBOUND_EVENT_API=ON and -DBUILD_LIBEVENT2=ON.
Is this behaviour an error, or should I call event_base_loop repeatedly until it returns 1? But if I have multiple requests at the same time, how do I know when to call getdns_context_destroy?
Gdb invocation:
gdb ./getdns-demo core
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./getdns-demo...
[New LWP 1094016]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./getdns-demo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 clear_my_event (ev=0x55add90e9210) at /home/user/projects/getdns-demo/3rd-party/getdns/src/ub_loop.c:153
153 (ev)->loop->extension->vmt->clear((ev)->loop->extension, &(ev)->gev);
(gdb) bt
#0 clear_my_event (ev=0x55add90e9210) at /home/user/projects/getdns-demo/3rd-party/getdns/src/ub_loop.c:153
#1 0x000055add761dfb8 in my_event_del (ev=0x55add90e9210) at /home/user/projects/getdns-demo/3rd-party/getdns/src/ub_loop.c:299
#2 0x00007f7bbf46308c in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#3 0x00007f7bbf46a9ae in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#4 0x00007f7bbf416257 in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#5 0x00007f7bbf3fe37e in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#6 0x00007f7bbf4126c9 in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#7 0x00007f7bbf4141f3 in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#8 0x00007f7bbf4142d9 in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#9 0x00007f7bbf3ed748 in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#10 0x00007f7bbf3eecd2 in ?? () from /lib/x86_64-linux-gnu/libunbound.so.8
#11 0x00007f7bbf3e9bcb in ub_ctx_delete () from /lib/x86_64-linux-gnu/libunbound.so.8
#12 0x000055add75ecaea in getdns_context_destroy (context=0x55add8dcfb40) at /home/user/projects/getdns-demo/3rd-party/getdns/src/context.c:1670
#13 0x000055add75e8494 in resolve_cdnskey_record (domain=<optimized out>, timeout_ms=<optimized out>, break_loop_if_solved=1) at /home/user/projects/getdns-demo/src/main.c:78
#14 0x000055add75e8049 in main () at /home/user/projects/getdns-demo/src/main.c:20
The text was updated successfully, but these errors were encountered:
When the request created by a
getdns_general
call invoces thecallbackfn
withGETDNS_CALLBACK_TIMEOUT
then calling ofgetdns_context_destroy
immediately after theevent_base_loop
crashes. The sample code is at gitlab. Schematically:Getdns
(Ubuntu 20.04
;getdns
branchdevelop
) is configured with-DENABLE_UNBOUND_EVENT_API=ON
and-DBUILD_LIBEVENT2=ON
.Is this behaviour an error, or should I call
event_base_loop
repeatedly until it returns 1? But if I have multiple requests at the same time, how do I know when to callgetdns_context_destroy
?Gdb invocation:
The text was updated successfully, but these errors were encountered: