Re: tor broken on 20202 / earmv7?

[Leonardo Taccari <leot%NetBSD.org@localhost>]

Hello Greg and John,
(TLDR; the problem is probably backtrace(3) related, adding
`CONFIGURE_ENV+= ac_cv_search_backtrace=no' seems to workaround this
problem.)

John Klos writes:
> Hi,
>
> > rather than the usual 4 or so lines, I get nothing and the process is
> > sitting as parked, doing nothing, using no CPU time.  This goes on for
> > days - I literally let one sit 5 days like this.  The rest of the things
> > on the machine work fine.  Because the script doesn't return, the rest
> > of the rc.d scripts don't run, and ssh doesn't start.
> >
> > A build of tor from the same pkgsrc branch, with the same 9-stable date,
> > but on i386 works normally.
> >
> > I wonder if
> >
> >  anyone else has seen similar trouble?
> >
> >  anyone else has tor working on 9-stable on earmv7/RPI3/?
>
> Yes:
>
> http://mail-index.netbsd.org/port-arm/2020/02/06/msg006482.html
>
> I'm currently running TOR in a netbsd-8 chroot on the same system, and it 
> works fine. I haven't had time yet to look in to this to see what's up.
> [...]

I have seen that too (IIRC it worked fine with a netbsd-9 of July/Aug
2019, with tor-0.4.0.5, but the version of tor is probably not
relevant).

The easiest way to reproduce the hang - to also avoid possible root or
tor users permissions - is via just:

 % tor --version

Unfortunately I have still not properly investigated it but running
tor-0.4.3.6nb1 under gdb - on a netbsd-9 of Jul 3 on earmv7hf - built
with CFLAGS=-g and INSTALL_UNSTRIPPED=yes - apart the SIGILLs (that
should be expected given the openssl use and probably harmless) its ends
up with a SIGSEGV in the backtrace(3) use:

 (gdb) bt
 #0  0x62eaf698 in _Unwind::LocalAddressSpace::get32 (this=0x62f07b7c, addr=4294967256)
     at /usr/src/sys/lib/libunwind/AddressSpace.hpp:85
 #1  _Unwind::LocalAddressSpace::getP (this=0x62f07b7c, addr=4294967256) at /usr/src/sys/lib/libunwind/AddressSpace.hpp:97
 #2  _Unwind::DwarfInstructions<_Unwind::LocalAddressSpace, _Unwind::Registers_arm32>::getSavedRegister (addressSpace=...,
     registers=..., cfa=cfa@entry=4, savedReg=...) at /usr/src/sys/lib/libunwind/DwarfInstructions.hpp:72
 #3  0x62eaf900 in _Unwind::DwarfInstructions<_Unwind::LocalAddressSpace, _Unwind::Registers_arm32>::stepWithDwarf (addressSpace=...,
     pc=<optimized out>, fdeStart=<optimized out>, registers=..., ctx=ctx@entry=0x7ff53158)
     at /usr/src/sys/lib/libunwind/DwarfInstructions.hpp:143
 #4  0x62dcb680 in _Unwind::UnwindCursor<_Unwind::LocalAddressSpace, _Unwind::Registers_arm32>::stepWithDwarfFDE (this=0x7ff53158)
     at /usr/src/sys/lib/libunwind/UnwindCursor.hpp:84
 #5  _Unwind::UnwindCursor<_Unwind::LocalAddressSpace, _Unwind::Registers_arm32>::step (this=0x7ff53158)
     at /usr/src/sys/lib/libunwind/UnwindCursor.hpp:55
 #6  _Unwind_Backtrace (callback=0x62f20a00 <tracer>, ref=ref@entry=0x7ff532f4) at /usr/src/sys/lib/libunwind/libunwind.cxx:310
 #7  0x62f20a88 in backtrace (arr=arr@entry=0xf3a0b68 <cb_buf>, len=len@entry=256) at /usr/src/lib/libexecinfo/unwind.c:69
 #8  0x0f299940 in install_bt_handler () at src/lib/err/backtrace.c:260
 #9  configure_backtrace_handler (tor_version=<optimized out>) at src/lib/err/backtrace.c:353
 #10 0x0f299f54 in subsys_torerr_initialize () at src/lib/err/torerr_sys.c:21
 #11 0x0f0dba70 in subsystems_init_upto (target_level=100) at src/app/main/subsysmgr.c:142
 #12 0x0f0d90a0 in tor_run_main (tor_cfg=0x62f3a000) at src/app/main/main.c:1230
 #13 0x0f0d7898 in tor_main (argc=1, argv=0x7ff535ac) at src/feature/api/tor_api.c:164
 #14 0x0f2ae640 in main (argc=<optimized out>, argv=<optimized out>) at src/app/main/tor_main.c:32

I have workarounded that by adding:

 CONFIGURE_ENV+=         ac_cv_search_backtrace=no

To avoid backtrace(3) use.

(I hope to further investigate it in the next days, maybe finding a
simpler and isolated reproducer.)