I just had another similar hang, this time in git, while trying to pull pkgsrc/wip: ....... [Switching to LWP 2518 of process 2823] 0x000072b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt
Thread 2 (LWP 2823 of process 2823): #0 0x000072b102a4551a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x000072b10320c754 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x0000000000549842 in preload_index () #3 0x0000000000558178 in refresh_index () #4 0x00000000004252f0 in cmd_status () #5 0x00000000004053fe in handle_builtin () #6 0x0000000000406301 in cmd_main () #7 0x00000000005ea9a3 in main () Thread 1 (LWP 2518 of process 2823): #0 0x000072b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x000072b103209791 in ?? () from /usr/lib/libpthread.so.1 #2 0x000072b102ad6d0a in je_malloc_mutex_lock_slow () from /usr/lib/libc.so.12 #3 0x000072b102b0e4f1 in je_arena_choose_hard () from /usr/lib/libc.so.12 #4 0x000072b102ab583f in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 #5 0x000072b102ab5a89 in je_tsd_tcache_enabled_data_init () from /usr/lib/libc.so.12 #6 0x000072b102ab1b09 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 #7 0x000072b102b0e82d in malloc () from /usr/lib/libc.so.12 #8 0x00000000005cbed5 in xrealloc () #9 0x00000000005a04d0 in strbuf_grow () #10 0x00000000005aa74b in lstat_cache_matchlen () #11 0x00000000005aa885 in threaded_has_symlink_leading_path () #12 0x00000000005495b8 in preload_thread () #13 0x000072b10320bee0 in ?? () from /usr/lib/libpthread.so.1 #14 0x000072b102a92370 in ?? () from /usr/lib/libc.so.12 #15 0x0000000000200000 in ?? () #16 0x0000000000000000 in ?? () .... The system is from today: $ uname -a NetBSD ymir 9.99.67 NetBSD 9.99.67 (GENERIC) #4: Tue Jun 16 09:10:01 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC am d64 Chavdar On Thu, 11 Jun 2020 at 00:19, Andrew Doran <[email protected]> wrote: > > On Mon, Jun 08, 2020 at 03:38:44PM +0100, Chavdar Ivanov wrote: > > On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov <[email protected]> wrote: > > > > > > Hi, > > > > > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > > > ... ; quit sorted it out. > > > > > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov <[email protected]> wrote: > > > > > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger <[email protected]> wrote: > > > > > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > > > > > Just to mention that after I quit gdb and detached from the process > > > > > > it > > > > > > continued and completed the build . . . > > > > > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > > > > > The second hung sample - with git - also completed OK after I quit > > > > gdb... > > > > I had another three cmake hangs just like this today, while rebuilding > > bits of kf5. > > > > Just to confirm - the moment one answers 'y' to the question whether > > to leave gdb the process continues and the build succeeds. > > > > This is somewhat annoying; although it does not stop the rebuild > > process, it makes it impossible to complete unattended. > > I just made some more changes to libpthread today that may help. I'll try > building KDE soon. > > Cheers, > Andrew -- ----
