GitHub PushEvent at 2014-05-16 18:52:55
Repository: nethack4
Actor: dtsund
Payload: {"shas":[["6aa494ebaffe688b069cf399f9567d912e883626","5598181697308f6ee0547b1599e7423eb23ade24@csclub.uwaterloo.ca","Fix more unprotected `newsym`s.\n\nFixes #470","Sean Hunt",true],["a20623660d0a136eaa283d66ebac59437cd03043","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Merge remote-tracking branch 'coppro/savebreak' into savebreak","Alex Smith",true],["4010cdd35ea2d7b575de2049774e658fd5fa56ef","5598181697308f6ee0547b1599e7423eb23ade24@csclub.uwaterloo.ca","Remove a useless line of code.\n\nThis is covered by checks in the naming code for an ended game.","Sean Hunt",true],["6c4103f30484f19da01bfe64d8ae7c05ae5ed05a","5598181697308f6ee0547b1599e7423eb23ade24@csclub.uwaterloo.ca","Fix an impossible in the ring code.\n\nMajor thinko here.","Sean Hunt",true],["c7fecc48b282e4770f9fb973a0f3404854b72f2d","5598181697308f6ee0547b1599e7423eb23ade24@csclub.uwaterloo.ca","Ensure that timeout order is preserved.\n\nFixes more timer desyncs","Sean Hunt",true],["c71dba111bd2e96d282a1021d96f77288021ec65","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Various race condition fixes\n\nI'm not sure if I've got them all, but this closes up quite a few\nholes that were letting those infamous 3-second delays sneak by.\n\nMain issue at the moment: sigprocmask() isn't guaranteed to work in\nsingle-threaded programs. We could use pthread_sigmask() instead,\nbut that would mean linking against pthreads even when we never\ncreate any other threads. (We don't create threads, but SDL will\nsometimes create them on our behalf.) There aren't any particularly\nclean solutions to this, AFAICT. The current solution is clean, but\nsadly, it's UB (although it seems to work on Linux). Perhaps we\nshould link against pthreads no matter what, purely to use the\nthread-safe version of sigprocmask.","Alex Smith",true],["77a86968c5d6a538f8715dc319a455d91f75bb11","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Always link against pthreads, even for tty play\n\nWe only use one thread for tty play, but always using the thread-safe\nversion of sigprocmask() is the easiest way to avoid thread-related\nUB (libnethack shouldn't care whether it's linked against a thread-\nusing interface or not). Incidentally, the old code is AFAICT\nperfectly fine on Linux, where the restrictions on sigprocmask() in\nmultithreaded processes are to stop you blocking SIGRTMIN-1 or\nSIGRTMIN-2 (signals that aren't available to the user anyway, as can\nbe seen from the negative numbers, but which do exist and thus are\naffected by sigfillset()). However, it's best to avoid UB so as to\nkeep things working on other systems.\n\nI chose to not use the \"-pthread\" compiler switch because it\napparently isn't portable between systems. Instead, I emulate its\neffect by hand, using \"-D_REENTRANT\" (the actual \"link against\npthreads\" part of it is handled by aimake).","Alex Smith",true],["59958b84ed474fcd00fdff6a42b66682b4e2d950","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Add debugging code to file locking (not compiled by default)\n\nWatching this with eight running games is both informative, and fun\nto look at. Note that the debug code is not portable (it doesn't work\ncorrectly on tty, and is vulnerable to race conditions that corrupt\nstderr); however, it's good enough for debugging.","Alex Smith",true],["f6884f0204efbbda13607023676aedcea290237e","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Fix a silly oversight in SIGRTMIN+1 retrying\n\nSA_RESETHAND is good because it lets you know when you forget to set\nthe signal handler. Like I did here.","Alex Smith",true],["cc995a4eb4450a36b5b0123ed8f261ebee049134","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Fix another race condition\n\nThis one was really subtle (especially as it wasn't in files.c). The\nproblem is that locking the logfile before recording it in\nprogram_state means that should another process want access to the\nlogfile in that instant before we record where it is, this process\nwill dutifully unlock stdin, then wait for the other process to say\nthat they've got the lock we just \"released\", forming a deadlock.\n\nThere are at least two known race conditions left:\n- There's no lock preventing the file lengthening between\n  log_replay_input and log_reply_no_more_options, and if it happens\n  to lengthen at that precise moment, we get a desync;\n- SDL_PushEvent isn't as async-signal-safe as I thought it was; it\n  will freeze the process if the signal happens to arrive inside a\n  call to malloc(). This is frustrating and possibly hard to fix,\n  given that merging everything into one event loop is the normal\n  way to make a function async-signal-safe. If SDL doesn't provide\n  a method of doing that, we have to generate fake input by bouncing\n  it off the OS kernel somehow (this was the trick that was commonly\n  used before pselect() was invented for the POSIXy equivalent).","Alex Smith",true],["a798df06774a25be7f82300c7c0cb25a7030b18c","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Fixes to getch() interruption in the SDL uncursed backend\n\nThis fixes the race condition on malloc, and also changes the way\nselect() is used because the old version couldn't possibly work on\nWindows due to API differences (I'm not sure whether the new version\ndoes or not, but it has a better chance). This is done by replacing\nthe \"correct\" threading/event loop style with polling, which upsets\nme; however, SDL has no async-signal-safe way to post events (because\nit uses malloc for events, and malloc is not async-signal-safe), so\npolling is needed somewhere, and SDL does polling every 10ms anyway.\nThus, we simply use the same poll interval as SDL, and get only a\nminimal performance penalty.","Alex Smith",true],["5a8a0a3f6285d1eb44e203424fc7e1abd48a9593","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Don't desync when a save file lengthens during input routines\n\nInstead, we let the server cancel queue up, send the request to the\nclient anyway, and have it immediately cancelled. There are more\nefficient ways to do this, of course, but this will do for now.","Alex Smith",true],["3e9111b7c1f6b0323b24985428c82e7c9facef86","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Plug a memory leak","Alex Smith",true],["3ef7325b7bd3a6c73fb4d6bf06825510882cadde","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Plug another memory leak","Alex Smith",true],["73b7d3855772e44983f43ea731f2a8bec0ef10c5","5598181697308f6ee0547b1599e7423eb23ade24@csclub.uwaterloo.ca","Merge remote-tracking branch 'ais523/savebreak' into savebreak","Sean Hunt",true],["29afd89557c7dcb351c57337d72fb8ce06a9b659","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Async-signal-safety in multiprocess play\n\nHow is sigtimedwait() not async-signal-safe? This replaces it with\npselect, and does a few optimizations along the way.\n\nThis is still not 100% correct because there's no sigprocmask variant\nthat's both thread-safe and async-signal-safe. I'm hoping that this\nis a mistake in the documentation for pthread_sigmask on my system\n(i.e. it is safe, but isn't marked as such); it says it's identical\nto sigprocmask, which is safe, after all.\n\nThere's still a race condition lurking here; I noticed this while\ndebugging that. (The problem is that it's possible for three\nprocesses to set up a never-ending cycle of 1-then-2 signals. I'm\nunclear whether it's better to prevent such chains starting, or to\nprevent them lasting when they start; I'm also unclear on how it\nmanaged to get started in the first place.)","Alex Smith",true],["15b553b19c1742bb39b72af6dadb1750e936cb0a","5598181697308f6ee0547b1599e7423eb23ade24@csclub.uwaterloo.ca","Clean up trap.c `newsym`s.\n\nThis should fix yet another newsym bug and head a few more potential ones at the\npass.","Sean Hunt",true],["c9c7799dab1ccdcb94ffe81593497f165779f388","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Remove all known UB from the multiprocess play code\n\nI had to delve into the dark corners of POSIX to do this. As far as I\ncan tell, the only portable way to unblock just the signals that are\nbeing handled, while in a signal handler in a multithreaded process,\nis to use the getcontext() buffer passed in a sigaction callback\n(which is basically a sigsetjmp buffer, except that the structure is\nnot 100% opaque; the signal mask and stack are the only portably\naccessable fields). getcontext() was removed from POSIX because\nsetcontext() doesn't actually work, but the third argument to\nsigaction() is still there, even if this is the only portable use to\nbe made of it.\n\nThe other callbacks (apart from the SIGALRM callback) were converted\nover to the three-argument form too, because I'm planning to use the\nsecond argument in a future commit.\n\nThis change also ensures we don't overwrite other people's errnos.\nQuite a few errno-setting calls are defined behaviour inside a signal\nhandler, so setting and reading errno must be too.","Alex Smith",true],["c038c6d91c34277d1da873041954afa639ce52f3","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Exit \"normally\" on hangup, don't just crash\n\nThis is so that the terminal deinitializes properly, letting me\ndo a killall -HUP nethack4 to kill all processes without screwing up\nthe terminals they run on. Fixes #345; it was marked as trivial, but\nwas really getting on my nerves.","Alex Smith",true],["5ff06497bd383c07b8c538dc27672ff5e41477aa","05e896af68d9ff60c4b413a55719fb80907d550e@nethack4.org","Let's try something else with respect to multiprocess play\n\nThe previous method didn't scale above more than 4 or 5 processes in\ntty play; there were just too many pointless retransmissions. This\nalternative version is immune to that, and also avoids a bunch of\nproblems that the other method had (some of which had workarounds,\nsome of which didn't).\n\nSadly, though, it still isn't working properly for 3 or more\nprocesses, and there doesn't seem to be any reason for this. I even\ntraced the syscalls, and they show something impossible happening\n(pselect() blocking a signal that isn't in its signal mask), and\nsomething that I can't reproduce outside the NH4 setting. I suspect\nI'm missing something. Nonetheless, commiting this for now.","Alex Smith",true]],"size":36,"ref":"refs/heads/savebreak","head":"bed66f3aacda6dd06fa762a5c264823080dab4c6"}