[I still can not produce the problem below on demand. It seems racy with no fixed context producing the problem as far as which port is building. But the general structure of what hangs is the same each time so far.]
The following is just an FYI for the other qemu-arm-static tied problem that I regularly run into. I do not have much useful information so far. It is not clear how I'd get such information. I still fairly frequently see the hang-up-error when lld is emulated and does not have --no-threads (so that it creates about as many threads as "cpus". The context involved has had 28 Hyper-V "cpus". Attaching-then-detaching with gdb gets the process going again. When lld is native, I've never seen such a hangup. Just for illustration (a 28 "cpu" under-Hyper-V context for the example): Reading symbols from /usr/local/bin/qemu-arm-static...done. (gdb) attach 14501 Attaching to program: /usr/local/bin/qemu-arm-static, process 14501 [New LWP 101722 of process 14501] [New LWP 101937 of process 14501] [New LWP 101967 of process 14501] [New LWP 102144 of process 14501] [New LWP 102153 of process 14501] [New LWP 102128 of process 14501] [New LWP 102166 of process 14501] [New LWP 102178 of process 14501] [New LWP 102251 of process 14501] [New LWP 102266 of process 14501] [New LWP 102268 of process 14501] [New LWP 102123 of process 14501] [New LWP 102475 of process 14501] [New LWP 102477 of process 14501] [New LWP 102478 of process 14501] [New LWP 102479 of process 14501] [New LWP 102481 of process 14501] [New LWP 102482 of process 14501] [New LWP 102483 of process 14501] [New LWP 102484 of process 14501] [New LWP 102485 of process 14501] [New LWP 102487 of process 14501] [New LWP 102488 of process 14501] [New LWP 102489 of process 14501] [New LWP 102490 of process 14501] [New LWP 102124 of process 14501] [New LWP 102493 of process 14501] [New LWP 102494 of process 14501] [New LWP 102495 of process 14501] [Switching to LWP 100873 of process 14501] _umtx_op () at _umtx_op.S:3 3 RSYSCALL(_umtx_op) (gdb) info threads Id Target Id Frame * 1 LWP 100873 of process 14501 _umtx_op () at _umtx_op.S:3 2 LWP 101722 of process 14501 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 3 LWP 101937 of process 14501 _umtx_op () at _umtx_op.S:3 4 LWP 101967 of process 14501 _umtx_op () at _umtx_op.S:3 5 LWP 102144 of process 14501 _umtx_op () at _umtx_op.S:3 6 LWP 102153 of process 14501 _umtx_op () at _umtx_op.S:3 7 LWP 102128 of process 14501 _umtx_op () at _umtx_op.S:3 8 LWP 102166 of process 14501 _umtx_op () at _umtx_op.S:3 9 LWP 102178 of process 14501 _umtx_op () at _umtx_op.S:3 10 LWP 102251 of process 14501 _umtx_op () at _umtx_op.S:3 11 LWP 102266 of process 14501 _umtx_op () at _umtx_op.S:3 12 LWP 102268 of process 14501 _umtx_op () at _umtx_op.S:3 13 LWP 102123 of process 14501 _umtx_op () at _umtx_op.S:3 14 LWP 102475 of process 14501 _umtx_op () at _umtx_op.S:3 15 LWP 102477 of process 14501 _umtx_op () at _umtx_op.S:3 16 LWP 102478 of process 14501 _umtx_op () at _umtx_op.S:3 17 LWP 102479 of process 14501 _umtx_op () at _umtx_op.S:3 18 LWP 102481 of process 14501 _umtx_op () at _umtx_op.S:3 19 LWP 102482 of process 14501 _umtx_op () at _umtx_op.S:3 20 LWP 102483 of process 14501 _umtx_op () at _umtx_op.S:3 21 LWP 102484 of process 14501 _umtx_op () at _umtx_op.S:3 22 LWP 102485 of process 14501 _umtx_op () at _umtx_op.S:3 23 LWP 102487 of process 14501 _umtx_op () at _umtx_op.S:3 24 LWP 102488 of process 14501 _umtx_op () at _umtx_op.S:3 25 LWP 102489 of process 14501 _umtx_op () at _umtx_op.S:3 26 LWP 102490 of process 14501 _umtx_op () at _umtx_op.S:3 27 LWP 102124 of process 14501 _umtx_op () at _umtx_op.S:3 28 LWP 102493 of process 14501 _umtx_op () at _umtx_op.S:3 29 LWP 102494 of process 14501 _umtx_op () at _umtx_op.S:3 30 LWP 102495 of process 14501 _umtx_op () at _umtx_op.S:3 (gdb) detach Just FYI, a little detail: The /usr/local/bin/qemu-arm-static above was the one running lld emulated. Thread 1 and threads 3-30 are similar by the call chain, although thread 1 has main. Thread 2 is different in general. With --no-thread the fanout does not happen. So far I've never had a hangup with --no-thread. (Overall using --no-thread is messy for builds of many ports because the gcc*'s ld's reject the command line option and this leads to build failures. Ports has no equivalents of LDFLAGS.lld+=-Wl,--no-threads to make the option only show up for lld. There are ports that mix clang with gcc's ld instead of using lld so knowing just the compiler in use is insufficient context.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
