"could not create control compt"

[gvanem]

I'm on Win-10 and seems to have built Unbound and the Pytho3 module OK.
Test outputs from:

• libunbound/python/examples/async-lookup.py: Resolve error: could not fork

• libunbound/python/examples/ns-lookup.py: Result:
  raw data: 05 70 69 70 69 74 03 63 69 73 05 76 75 74 62 72 02 63 7A 00;05 72 68 69 6E 6F 03 63 69 73 05 76 75 74 62 72 02 63 7A 00
  host: pipit.cis.vutbr.cz.
  host: rhino.cis.vutbr.cz.

• libunbound/python/examples/dns-lookup.py: Result: ['217.31.205.50']

• libunbound/python/examples/example8-1.py: Result:
  raw data: 00 14 02 6D 78 03 6E 69 63 02 63 7A 00;00 0A 04 6D 61 69 6C 03 6E 69 63 02 63 7A 00
  priority:10 address:mail.nic.cz.
  priority:20 address:mx.nic.cz.
  Result:
  raw data: D9 1F CD 32
  address:217.31.205.50
  Result:
  raw data: 01 64 02 6E 73 03 6E 69 63 02 63 7A 00;01 61 02 6E 73 03 6E 69 63 02 63 7A 00;01 62 02 6E 73 03 6E 69 63 02 63 7A 00
  host: a.ns.nic.cz.
  host: b.ns.nic.cz.
  host: d.ns.nic.cz.

Seems pretty okay to me. But using an Python3 adaption of ubmodule-tst.py, shows these errors:

bin/unbound.exe -ddvv -c F:/MinGW32/src/inet/DNS/Unbound/run/example.conf
[1696943035] unbound.exe[12256:0] notice: Start of Unbound 1.18.1.
[1696943035] unbound.exe[12256:0] debug: chdir to F:/MinGW32/src/inet/DNS/Unbound/run
[1696943035] unbound.exe[12256:0] debug: switching log to stderr
[1696943035] unbound.exe[12256:0] debug: module config: "python validator iterator"
[1696943035] unbound.exe[12256:0] notice: init module 0: python
[1696943035] unbound.exe[12256:0] info: F:/MinGW32/src/inet/DNS/Unbound/run/ubmodule-tst.py: script loaded.
[1696943035] unbound.exe[12256:0] info: F:/MinGW32/src/inet/DNS/Unbound/run/ubmodule-tst.py: init called, module id is 0 port: 53 script: <u
nboundmodule.config_strlist; proxy of <Swig Object of type 'config_strlist *' at 0x000001BA27916040> >
[1696943035] unbound.exe[12256:0] notice: init module 1: validator
[1696943035] unbound.exe[12256:0] notice: init module 2: iterator
[1696943035] unbound.exe[12256:0] debug: target fetch policy for level 0 is 3
[1696943035] unbound.exe[12256:0] debug: target fetch policy for level 1 is 2
[1696943035] unbound.exe[12256:0] debug: target fetch policy for level 2 is 1
[1696943035] unbound.exe[12256:0] debug: target fetch policy for level 3 is 0
[1696943035] unbound.exe[12256:0] debug: target fetch policy for level 4 is 0
[1696943035] unbound.exe[12256:0] error: could not create control compt.
[1696943035] unbound.exe[12256:0] fatal error: Could not initialize main thread

I did cook up an run/example.conf based on doc/example.conf.in containing:

server:
  module-config: "python validator iterator"
  python-script: "F:/MinGW32/src/inet/DNS/Unbound/run/ubmodule-tst.py"

What is this "control compt" an how can I fix this?

System:

• Unbound version: 1.18.1
• OS: Win-10
• unbound -V output:

Version 1.18.1

Configure line: --with-libexpat --with-openssl --with-pyunbound --with-pythonmodule
[warn] signal.c: socketpair: Programmet har ikke kalt WSAStartup, eller WSAStartup mislyktes.
Linked libs: event winsock (it uses WSAWaitForMultipleEvents), OpenSSL 3.2.0-alpha3-dev
Linked modules: dns64 python cachedb respip validator iterator

BSD licensed, see LICENSE in source package for details.
Report bugs to https://github.com/NLnetLabs/unbound/issues

The [warn] signal.c: seems unimportant for this issue (WSAStartup() was not called).

[wcawijngaards]

The error is created when unbound is making the internal control communication point, it is from util/tube.c. That depends on some config.h defines, like USE_WINSOCK and HAVE_SOCKETPAIR. It has a separate implementation for windows, when the variable is defined. When it is not defined, it assumes like Linux or so, and then uses socketpair(). If this was weirdly compiled, it would easily create such an error, where a pipe is created but that does not work, and it fails.

Yes I think the warning in the -V output it harmless too, for this issue.

The routine tube_create that is called for it logs more when verbosity is 4 or higher, so with that enabled more debug output is produced about this issue. But it seems to fail in tube.c:tube_setup_bg_listen, assuming it is taking the windows code path, and that detected okay, and then calls ub_winsock_register_wsaevent, but that from util/winsock_event.c only fails if the cap on number of items is reached. Something that should only happen with many items listened to, like interface statements. So I am not sure what is going on.

[gvanem]

Seems that my build did not define -DUSE_MINI_EVENT.
Adding that, everything works better: a bin/unbound.exe -ddvv -c F:/MinGW32/src/inet/DNS/Unbound/run/example.conf
and calling dig @127.0.0.1 -t mx google.com in another window, returns valid info.
And ubmodule-tst.py prints:

[1697007461] unbound.exe[19308:0] info: pythonmod: operate called, id: 0, event:module_event_moddone
Query:   ['']Type: NS (2)Class: IN (1)
Return MSG rep   :: flags: 8400, QDcount: 1, Security:2, TTL=86400
           qinfo :: qname: [''] . type: NS class: IN
RRSets: 27
0 : [''] . flags: 0000type: NS (2) class: IN (1)
    RRDatas: 14
     0 : TTL= 86400 RR data:
   ...

Seems not be fully Python3 compatible, but pretty cool afterall.

So bottom-line, using libevent 2.2.1 does not work for Windows!!?
I'll try to rebuild with the latest libevent.

[wcawijngaards]

Glad that it works! The libevent compile for windows has not been used, so there is no previous data I can tell you about. Could be nice if that works.

For the python3 compatibility, I think this is about the printout after the pythonmod log line, that is a printout from the python module itself. Is that a python3 issue in an example python script, it would be nice to know what part of the example is a problem?

[gvanem]

. Is that a python3 issue in an example python script, it would be nice to know what part of the example is a problem?

Some use of ord(x) that works in Python 2.x but not in my Python 3.10. Pretty gibberish to me.
Please try ubmodule-tst.py with your Python 3.x.

But I have other issues with MSVC and the Python-module etc. that I raise here. E.g. this:

   //SWIG will see the ub_ctx as a class
   struct ub_ctx {
   };

Throws this error in MSVC:

libunbound_wrap.c(3633,3): error C2016: C requires that a struct or union have at least one member
  };
  ^

Not sure which C-standard says what about this issue. So would this be OK?

  struct ub_ctx {
    int dummy;
  };

[wcawijngaards]

Not sure if msvc can compile the code, but the dummy member variable is no problem. Added it in the commit.

[wcawijngaards]

The pythonmod/ubmodule-tst.py file should work better with Python 3.x with the commit referenced. That makes it work with Python-3.10 for me.

[gvanem]

Tried with MSVC and it works fine with Python 3.10.
Still other issues that I can create another PR for.