Hi Pieter, On Tue, Jun 12, 2018 at 08:09:08PM +0200, PiBa-NL wrote: > Is there something i can do to find out more info if it happens again? Or > maybe before that build with more specific debug info so if it happens again > more info would be retrievable.?. > (My usual way of 'debugging' with the relatively easy to reproduce issues is > just cramming a lot of printf statements into the code until something makes > sense., but with a issue that only happens once in a blue moon (sofar), that > doesn't work very well...)
Building with -DDEBUG_THREAD and -DDEBUG_MEMORY can help to get a more exploitable core file which will reveal where a given lock was already taken. Be careful that it will slightly increase the CPU usage though. > For the moment it hasn't happened again. i suspend/resume the vm it happened > on almost daily (that's running on my workstation witch is shutdown > overnight) the vm also has haproxy running on it and some other stuff.. > > If it does happen again, would there be any other gdb information helpful? > Inspecting specific variables or creating a memory dump or something.? > (please give a hint about the comment/option to call if applicable/possible, > i'm still a rookie with gdb..) p.s. i'm on FreeBSD not sure if that matters > for some of gdb's available options or something.. Creating a dump is often quite useful. You can do it with the command "generate-core-file". A "bt full" and "info thread" will also be needed as you did last time. I cannot guide you through the commands used to debug the threads however because I don't know them, I think I remember you need to print the contents of the lock itself (eg: "p foo->lock"). > Would the complete configuration be helpfull? There is a lot of useless > stuff in there. because its my test/development test vm, and because of lack > of it happening again there is no good opportunity to shrink it down to > specific options/parts.. Well probably not, though if at least to keep it unmodified with the unstripped executable and the upcoming core, that may be useful afterwards. Thanks! Willy
