https://bugzilla.mindrot.org/show_bug.cgi?id=2434
--- Comment #7 from Damien Miller <[email protected]> --- TL;DR signals are hard, lets go do some neurosurgery Looking at this again, this is quite difficult to fix so long as our progress meter runs in signal context. Even if we got rid of the malloc calls in utf8.c, that code can never be safe to run in a signal handler - none of the mb*/wc* standard library functions are signal-safe. Some alternatives: 1. Use a thread Nope. 2. Make utf8.c signal-safe This would mean ditching use of mb*/wc* and redoing it longhand. Not impossible but big and brittle. Probably a non-starter. 3. Arrange for the formatting (at least of the filename) to happen in a non-signal context Perhaps we could do it in scpio somehow? The problem here is that it is only called at present for complete writes from atomicio, but perhaps we could add some heuristic that allowed it to be called when the underlying read/write was interrupted by a signal too? We'd still need to be careful though - we couldn't naively update the string that gets written by the progress meter code as a SIGALRM could come along while we're updating it. I think we could do it by doing something like: replacing the filenames with a short array of filenames, a sig_atomic_t index that points to the one that is safe to write to and a way to update the index. 4. Allow safe truncation of the filename in signal context. The main thing the progress meter code needs to do with the filename is truncate it appropriately when it doesn't fit the terminal's columns. The problem this presents for multibyte locales is picking the spots where we can safely split it. We could have start_progress_meter() record an array of "split points" and have refresh_progress_meter() pick the one that makes the sanitised filename fit. This might be the easiest to do, but we'd need a new API in utf8.c -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
