[Bug 204178] stress2 on arm64 thr1 hangs after printing pthread_join error

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204178

--- Comment #5 from Andrew Turner <Andrew at FreeBSD.org> ---
I have some code that inspects the state when the issue show up. Below is a
dump of the registers of the only thread in the process.

  x0 = 000000004048fd50
  x1 = 0000000000000011
  x2 = 0000000000000000
  x3 = 0000000000000000
  x4 = 0000000000000000
  x5 = 0000000000000001
  x6 = 0000000000000001
  x7 = 000000000000007f
  x8 = 00000000000001c6
  x9 = 0000000080000000
 x10 = 00000000000187dd
 x11 = 00000000000187dd
 x12 = 0000000000000001
 x13 = 000000004048fcd8
 x14 = 00000000000187dd
 x15 = 0000000000000000
 x16 = 0000000040485df8
 x17 = 00000000404fe8dc
 x18 = 0000000040801530
 x19 = 000000004048fd50
 x20 = 00000000000187dd
 x21 = 0000000040490000
 x22 = 000000004048fd50
 x23 = 0000000000412000
 x24 = 0000000000000000
 x25 = 00000000004014f0
 x26 = 0000000000000000
 x27 = 0000000000000000
 x28 = 0000000000000000
 x29 = 0000007fffffee50
  lr = 0000000040466eb0
  sp = 0000007fffffee40
 elr = 00000000404fe8e0
spsr = 90000000

I looked at the data passed to the kernel in x0 and found the owner of the lock
to be the current thread. I also looked at a stack trace and found we entered
the lock by the following calls:

_pthread_create -> _thr_alloc -> __thr_umutex_lock -> _umtx_op

The lock in _thr_alloc is, as far as I can tell, the only place within this
function we acquire this lock, and is protecting _tcb_ctor.

-- 
You are receiving this mail because:
You are on the CC list for the bug.