Tor crashes with stack trace when sandbox enabled and controller (arm) connects. This is a regression at some point between `c21377e7bcc70d2a456409225d8b2d91990a14cd` (good) and `a6688f9cbb930ad139a7f3886684fcadeec59d30` (bad). I haven't had a chance to bisect yet. If someone has an educated guess which commit might be at fault, that will save me a lot of time :) Tor 0.2.5.4-alpha-dev (git-95d47a74815ede0e) Debian Jessie, kernel 3.14-1-amd64 libseccomp-dev 2.1.1-1 To repro: * Enable sandbox, start tor. * Open arm * Observe that tor has crashed. log: ``` Jun 08 02:04:20.000 [notice] New control connection opened. ============================================================ T= 1402207460 (Sandbox) Caught a bad syscall attempt (syscall getrlimit) /usr/bin/tor(+0x123afa)[0x7f11e2773afa] /lib/x86_64-linux-gnu/libc.so.6(getrlimit64+0x7)[0x7f11e0d771e7] /lib/x86_64-linux-gnu/libc.so.6(getrlimit64+0x7)[0x7f11e0d771e7] /usr/bin/tor(set_max_file_descriptors+0x2e)[0x7f11e276144e] /usr/bin/tor(+0xd75d6)[0x7f11e27275d6] /usr/bin/tor(+0x31ed0)[0x7f11e2681ed0] /usr/bin/tor(connection_control_process_inbuf+0x1b44)[0x7f11e272d634] /usr/bin/tor(+0xc8b55)[0x7f11e2718b55] /usr/bin/tor(+0x34af1)[0x7f11e2684af1] /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414)[0x7f11e1cdc184] /usr/bin/tor(do_main_loop+0x195)[0x7f11e2686285] /usr/bin/tor(tor_main+0x18d5)[0x7f11e2689245] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f11e0cbab45] /usr/bin/tor(+0x32adb)[0x7f11e2682adb] ``` /usr/share/tor/tor-service-defaults-torrc: ``` DataDirectory /var/lib/tor PidFile /var/run/tor/tor.pid RunAsDaemon 1 User debian-tor ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie Log notice file /var/log/tor/log ``` torrc: ``` ORPort 9001 Sandbox 1 ``` (I see getrlimit mentioned in the comments of legacy/trac#9894, not sure if same bug.) **Trac**: **Username**: alphawolf