On Fri, Aug 02, 2019 at 11:26:48AM +0100, Simon McVittie wrote: > On Fri, 12 Jul 2019 at 11:16:53 +0100, Iain Lane wrote: > > I saw this on Ubuntu (9.1.0-8ubuntu1) but I've also reproduced this with > > 9.1.0-8 on sid (w/gcc-defaults from experimental to use gcc-9 by > > default). > > > > clutter's tests hang: > ... > > It's adding some stuff to a main loop and expecting it to finish when a > > particular signal handler is called. > > I can reproduce this with current unstable GLib, 2.60.6-1 (after reverting > the change that makes it explicitly build with gcc 8). > > In the non-working case, it looks as though the paint signal is not > getting emitted at all. The Clutter master clock appears to be the thing > that is meant to be scheduling GLib main-loop events in this case (and > then I got lost and couldn't work out what was wrong). Thanks for reproducing. For the record: at Debconf doko suggested to me that a way to start debugging this from the GCC end would be to produce one working and one "broken" build of the same version of glib2.0, and then copy object files from the broken to the working one until that too becomes broken. That sounded long / tedious / fiddly so we didn't manage to get round to doing it while we were both there, unfortunately. > I have been trying to reproduce this with the upstream GLib source code > so that I can try a build of GLib with ThreadSanitizer or AddressSanitizer, > but so far this has not been successful. Hmm, I thought I tried that and did manage to reproduce. Perhaps that's my memory being slightly faulty. Will try again (probably in a week after I'm back from holidays) if you don't beat me to it. Cheers, -- Iain Lane [ iain@orangesquash.org.uk ] Debian Developer [ laney@debian.org ] Ubuntu Developer [ laney@ubuntu.com ]
Attachment:
signature.asc
Description: PGP signature