Seg. Fault with 9pserve on MacBook Pro M1

[mek]

Hello, I was given my first MacBook Pro M1 with Ventura 13.4.1. Not really experienced with Mac M1s. I tried to get plan9port running and it seems the 9pserve will not run correctly.

Git checkout: cc4571f

% lldb -- 9pserve -u 'unix!/var/tmp/.ns.mek.1/test'
(lldb) target create "9pserve"
Current executable set to '9pserve' (arm64).
(lldb) settings set -- target.run-args  "-u" "unix!/var/tmp/.ns.mek.1/test"
(lldb) run
Process 62585 launched: '/Users/mek/plan9/bin/9pserve' (arm64)
Process 62585 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
    frame #0: 0x00000001a41b0724 libsystem_kernel.dylib`__pthread_kill + 8
libsystem_kernel.dylib`:
->  0x1a41b0724 <+8>:  b.lo   0x1a41b0744               ; <+40>
    0x1a41b0728 <+12>: pacibsp
    0x1a41b072c <+16>: stp    x29, x30, [sp, #-0x10]!
    0x1a41b0730 <+20>: mov    x29, sp
Target 0: (9pserve) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
  * frame #0: 0x00000001a41b0724 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001a41e7c28 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x00000001a40be46c libsystem_c.dylib`raise + 32
    frame #3: 0x0000000100006d48 9pserve`child at daemonize.c:38:3 [opt]
    frame #4: 0x0000000100006bfc 9pserve`_threadsetupdaemonize at daemonize.c:160:4 [opt]
    frame #5: 0x0000000100008820 9pserve`p9main(argc=3, argv=0x000000016fdfed90) at thread.c:729:3 [opt]
    frame #6: 0x000000010000d628 9pserve`main(argc=<unavailable>, argv=<unavailable>) at main.c:10:2 [opt]
    frame #7: 0x00000001a3e8ff28 dyld`start + 2236
(lldb) quit
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] y

I haven't seen are reports like this before so either I found something really really new (I have my doubts) or I am a dolt (much more likely) and I am missing something.

[mek]

Anybody have an hints on this or other things I could try to find a fix?

[mek]

Turns out that the namespace path was too long due to the how the filesystem was setup by the corporate masters.