Futex wait causing MUCK-wide lockup about fuzzball

[wyld-sw]

Could you give us a little more information about your environment? Which Linux distribution, compile options (from @Version), etc.

I read there was a linux bug with futex(), but that may be a red herring.

[kyanha]

Version: Muck2.2fb7.00a2(2) Compiled on: Sun Dec 18 2016 at 14:18:39 UTC
Options: DETACH GODPRIV IPV6 MCP RESOLVER SSL

Ubuntu 16.04, last patches approximately at the beginning of November 2016.

This is located on Linode.

Regarding the compile time, I accidentally triggered a rebuild when looking through the config.h header file. We haven't changed the code since the issue was filed. The most recent lockup was approximately 12 hours ago, 12/17/2016, 11:30 PM ET.

# uname -a
Linux tassmoj.sprmuck.org 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[charlesreiss]

I'm curious about being unable to load the database with the MUCK compiled in debug mode. Do we have any idea what's causing that? Can we at least get it working compiled with -g -O2 or similar so you can attach a debugger and possibly get a half-useful stacktrace the next time this happens?

[charlesreiss]

One possibility that comes to mind is that sig_reap() might do things which are not async-signal-safe, like calling vfprintf via log_status, which might cause a deadlock if the MUCK gets SIGCHLD while writing a log message (or malloc'ing if vfprintf mallocs, etc.)

A likely symptom of this would be the freeze occuring shortly after a forked database dump or a resolver process exit.

Actually, it does seem to happen in conjunction with a database dump to disk, based on timing.

[kyanha]

There's also a perhaps-related issue with resolver not dying properly? I haven't dug in to figure out where or why that's happening -- @sypherspace, can you submit a separate bug for the resolver issues?

@kyanha Done. See #42.

[wyld-sw]

#43 seems to resolve this. Feel free to reopen if the problem still exists.