On Wed, Aug 06, 2025 at 12:34:23PM +0100, Daniel P. Berrangé wrote: > On Wed, Aug 06, 2025 at 12:11:38PM +0100, Alex Bennée wrote: > > Daniel P. Berrangé <berra...@redhat.com> writes: > > > > > On Tue, Aug 05, 2025 at 07:57:38PM +0300, Manos Pitsidianakis wrote: > > >> On Tue, Aug 5, 2025 at 7:49 PM Daniel P. Berrangé <berra...@redhat.com> > > >> wrote: > > >> > > > >> > > > >> > Was there a specific place where you found things hard to debug > > >> > from the error message alone ? I'm sure we have plenty of examples > > >> > of errors that can be improved, but wondering if there are some > > >> > general patterns we're doing badly that would be a good win > > >> > to improve ? > > >> > > >> Some months ago I was debugging a MemoryRegion use-after-free and used > > >> this code to figure out that the free was called from RCU context > > >> instead of the main thread. > > > > > > We give useful names to many (but not neccessarily all) threads that we > > > spawn. Perhaps we should call pthread_getname_np() to fetch the current > > > thread name, and used that as a prefix on the error message we print > > > out, as a bit of extra context ? > > > > Do we always have sensible names for threads or only if we enable the > > option? > > I was surprised to discover we don't name threads by default, only if we > add '-name debug-threads=yes'. I'm struggling to understand why we would > ever want thread naming disabled, if an OS supports it ? > > I'm inclined to deprecate 'debug-threads' and always set the names when > available.
FYI, I'm working on a small series that will enable thread names and IDs to be printed by default with errors, and should post it sometime this week. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
