I can confirm this bug, with the same setup.

This is a good find. Thanks for posting the issue, and I think you nailed the problem.

I'm not sure the best solution either. A crash is never good. I can't completely remember why we even call nni_fini(), maybe just for good hygiene? I can only think of a couple use cases for calling it:

1. If trying to detect a memory leak with Valgrind, it will report that a lot of stuff leaked at the process exit
2. If a process is embedding a Python interpreter, this would allow it to shut it down and restart it (possibly)

Maybe we could add a global variable to pynng, a bool called nng_fini_at_exit, that gets checked when deciding whether to call nng_fini() or not. It should probably default to False to avoid any process-crashing race conditions.

Thoughts?

I think that solution is ok, and having it default to False is also good as for most people it probably would not make much of a difference as the process is anyway about to end. For added flexibility we could expose the nng_fini in the pynng api, so that the user can call it themselves at the appropriate time. In that case maybe we could even get rid of nng_fini_at_exit and _pynng_atexit and let the user himself register atexit.register() if it is necessary for the usecase (and have an corresponding section in the documentation about that)

I ran into the same bug and wrote a simple repro case. About half the time I get nni logs like OP.

#!/usr/bin/env python3

from pynng import Surveyor0, Respondent0, Timeout
import os
import signal
import threading
import traceback
import time

address = "tcp://127.0.0.1:13812"

def daemon(function):
    t = threading.Thread(target=function, daemon=True)
    print(f"Starting thread: {function.__name__}() as {t.name}")
    t.start()
    return t

def s():
    with Surveyor0(listen=address) as surveyor:
        surveyor.survey_time = 500  # milliseconds
        while True:
            surveyor.send(b"foo")
            try:
                while True:
                    m = surveyor.recv()
                    print(f"Got {m} from client")
            except Timeout:
                pass

def c():
    with Respondent0(dial=address) as responder:
        while True:
            m = responder.recv()
            print(f"Got {m} from server")
            responder.send(b"bar")

daemon(s)
time.sleep(0.1)
daemon(c)
time.sleep(2)

I ran into the same bug and wrote a simple repro case. About half the time I get nni logs like OP.

#!/usr/bin/env python3

from pynng import Surveyor0, Respondent0, Timeout
import os
import signal
import threading
import traceback
import time

address = "tcp://127.0.0.1:13812"

def daemon(function):
    t = threading.Thread(target=function, daemon=True)
    print(f"Starting thread: {function.__name__}() as {t.name}")
    t.start()
    return t

def s():
    with Surveyor0(listen=address) as surveyor:
        surveyor.survey_time = 500  # milliseconds
        while True:
            surveyor.send(b"foo")
            try:
                while True:
                    m = surveyor.recv()
                    print(f"Got {m} from client")
            except Timeout:
                pass

def c():
    with Respondent0(dial=address) as responder:
        while True:
            m = responder.recv()
            print(f"Got {m} from server")
            responder.send(b"bar")

daemon(s)
time.sleep(0.1)
daemon(c)
time.sleep(2)

I've forked and updated nng (and mbedtls) to the latest version, and the code does not crash anymore.
Also, I've seen that @broglep-work and another user made some patches in a fork here.
I will probably include these patchs in my branch as well