On Sat, 11 Jan 2020 14:26:12 +0100 Bernhard Übelacker <bernha...@mailbox.org> wrote:
> Could you recheck - could it be that this pid 309563 > was still running from a previous kicad session and > your hanging kicad was another, newer process? Definitely a new one. To retest: $ pgrep kicad [nothing] [run kicad, get it stuck] $ pgrep kicad 493905 Just a single one running. (gdb) bt #0 0x00007faf28a244bc in wxClassInfo::~wxClassInfo() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #1 0x00007faf2837c720 in __run_exit_handlers (status=0, listp=0x7faf284f9718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #2 0x00007faf2837c85a in __GI_exit (status=<optimized out>) at exit.c:139 #3 0x00007faf28366bc2 in __libc_start_main (main= 0x56538577f880, argc=1, argv=0x7fff267a6058, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff267a6048) at ../csu/libc-start.c:342 #4 0x000056538578412a in _start () To clarify, this was after simply clicking the windomanager [X] button to close the pcbnew window; I was intending to leave the toplevel kicad window still open. > Because, I guess, the __run_exit_handlers should just > run at process exit. > > The last line in your backtrace point to this line, > with a loop which would fit into the picture: > > https://sources.debian.org/src/wxwidgets3.0/3.0.4+dfsg-15/src/common/object.cpp/#L177 > > When you are in gdb and try to leave the current function > by "finish", do you get again to the debugger prompt, > or is it causing already the 100% CPU usage again? I'll try: (gdb) finish Run till exit from #0 0x00007faf28a244bc in wxClassInfo::~wxClassInfo() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 That returns to 100% CPU spin which I believe it'll continue on until SIGTERM. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/