Control: notfound -1 1.4~beta4ubuntu1 Control: found -1 1.4~beta4 Hi, On Thu, Jan 26, 2017 at 08:15:30PM -0500, Anders Kaseorg wrote: > Package: apt > Version: 1.4~beta4ubuntu1 > > (I also checked the code of 1.4~beta4, hence reporting here.) Thanks! Next time please don't report with a ubuntu version string through as the BTS doesn't know ubuntu version and will hence be a bit confused. I am fixing this with the control headers above. > I just had an ‘apt install’ process freeze when I resized its terminal > window. Attaching gdb revealed the backtrace below, showing that free() > was interrupted by the SIGWINCH handler, which calls Configuration::FindB, > which builds the first argument of checkFindConfigOptionType with the > std::string(const char *) constructor, which tries to call malloc(), > leading to a deadlock. Mhhh. the checkFindConfigOptionType path is new, was added by me (in ~beta3) and there is actually some benefit in avoiding the std::string by default (as by default that method will do nothing. Whitelisting is at that point really a developer only mode), so I committed a simple optimisation in that direction eliminating that malloc… > Probably the most straightforward solution is to have the signal handler > do nothing other than set a volatile sig_atomic_t flag, and defer the real > work to some safe point outside the handler. … but while "fixing" this specific instance the handler is far from trivial with multiple std::string creations (although, those might qualify for small-string optimisation), output generation (which perhaps uses only safe operations internally, but who knows) and and and … (since at least 1.1) which is far from trivial to change as these progress handlers have no event loop by themselves. They are called in reaction to messages received from dpkg which can be far and apart. They especially don't happen together with "normal" output of dpkg (or the things it runs in maintainerscripts) so that output will be "happily" garbled if we don't react to the window change 'instantly'… I have no immediate idea at least but with my mentioned commit we are at least back to a pre-beta3 state which seemed to have worked for a while now… (unsurprisingly, I couldn't reproduce the problem in a few test runs before or after – so just try to be lucky, I guess ;) ). Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature