Re: NetBSD 10.0 - configure test process hang

    Date:        Fri, 15 Nov 2024 20:22:44 +0100
    From:        Riccardo Mottola <[email protected]>
    Message-ID:  <[email protected]>

  | Sent with HTLM so lines hopefully don't wrap

You didn't send HTML format (and please don't!) and the lines did
wrap, but that's OK, it is obvious, and easy to deal with (no more
than a minor annoyance - nothing like as bad as HTML would be, which
I wouldn't attempt to read at all).

  |    0  1107 16464 51942  31  0 67104 20000 parked Il+  pts/1 0:06.39
  | ../src/emacs -batch --no-site-lisp --no-site-file --eval (setq
  | load-prefer-newer t) -f batch-

  |    0  4180 16464 55012  30  0 67104 20000 parked Il+  pts/1 0:06.66
  | ../src/emacs -batch --no-site-lisp --no-site-file --eval (setq
  | load-prefer-newer t) -f batch-


  |  |                               \-+- 16464 root /usr/pkg/bin/gmake
  | compile-targets NATIVE_DISABLED= TARGETS=./emacs-lisp/eieio.elc
  | ./emacs-lisp/eieio-base.elc .
  |  |                                 |--- 01107 root ../src/emacs -batch
  | --no-site-lisp --no-site-file --eval (setq load-prefer-newer t) -f
  | batch-byte-compile emac
  |  |                                 \--- 04180 root ../src/emacs -batch
  | --no-site-lisp --no-site-file --eval (setq load-prefer-newer t) -f
  | batch-byte-compile calc


  | Seems the two emacs processes are "parked"

Yes.

  | I tried attaching with gdb
  | sudo gdb --pid=01107
  |
  | but it didn't find the process.

Sorry, can't help with that, I am a gdb novice (once used much
better debuggers, and could never really fathom gdb for more than
fairly trivial stuff) - certainly I've never even attempted to use
gdb that way to attach to a running process.   But even if it did,
unless everything was compiled with -g (which it almost certainly
isn't - everything in this case means emacs, and all the libraries
it uses) the help it would offer would probably not be all that
much.

But you didn't do what I asked, run

	ps -ls -p 1107
	ps -ls -p 4180

and find out what threads exist in each process, and the state of
all of the threads, that might reveal more to someone.

But if what Martin said is correct, and it almost certainly is, this
is an ancient sparc multi-cpu problem, that no-one has been able to
find so far, so the best option might simply be to kill things once
they have reached this state and start again (without cleaning anything).

kre