Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:57:46Zhttps://gitlab.torproject.org/legacy/trac/-/issues/412Tor v0.1.2.12-rc segfaults after a while2020-06-13T13:57:46ZTracTor v0.1.2.12-rc segfaults after a whileuname -mrs
FreeBSD 6.2-RELEASE-p3 i386
Tor version 0.1.2.12-rc.
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading s...uname -mrs
FreeBSD 6.2-RELEASE-p3 i386
Tor version 0.1.2.12-rc.
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /lib/libssl.so.5...done.
Loaded symbols for /lib/libssl.so.5
Reading symbols from /lib/libcrypto.so.5...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /lib/libpthread.so.2...done.
Loaded symbols for /lib/libpthread.so.2
Reading symbols from /lib/libevent-1.2a.so.1...done.
Loaded symbols for /lib/libevent-1.2a.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x2827f537 in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x8110200 (runnable)]
[New Thread 0x8110000 (LWP 100098)]
[New Thread 0x80f4000 (runnable)]
[New LWP 100066]
(gdb) where
#0 0x2827f537 in pthread_testcancel () from /lib/libpthread.so.2
#1 0x28277ec8 in pthread_mutexattr_init () from /lib/libpthread.so.2
#2 0x28108450 in ?? ()
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Orumhttps://gitlab.torproject.org/legacy/trac/-/issues/409Tor doesn't treat 0 as a valid port2020-06-13T13:57:41ZTracTor doesn't treat 0 as a valid portTor does not treat the officially reserved port 0 as a valid port when considering
exit policies. For example, "reject *:0-19" would be summarixed as "reject *:1-19"
and would show up in the directory as such.
Actual version of tor is ...Tor does not treat the officially reserved port 0 as a valid port when considering
exit policies. For example, "reject *:0-19" would be summarixed as "reject *:1-19"
and would show up in the directory as such.
Actual version of tor is 0.1.2.12-rc, but that is not listed in the options.
Reference: http://www.iana.org/assignments/port-numbers
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Orumhttps://gitlab.torproject.org/legacy/trac/-/issues/363Refuse to start if /etc/resolv.conf cannot be read/parsed2020-06-13T13:57:13ZTracRefuse to start if /etc/resolv.conf cannot be read/parsedTor exit nodes currently assume a local nameserver listening on 127.0.0.1 if /etc/resolv.conf
cannot be found (or parsed, I would assume). However, in order to mitigate DNS issues with exit
nodes (i.e. those described in task #362), I t...Tor exit nodes currently assume a local nameserver listening on 127.0.0.1 if /etc/resolv.conf
cannot be found (or parsed, I would assume). However, in order to mitigate DNS issues with exit
nodes (i.e. those described in task #362), I think tor should refuse to start (or at least log a
warning/error to stderr) if this is the case. Of course, this does not solve all DNS issues, as
invalid DNS servers could still easily exist in /etc/resolv.conf, but it will at least act as a
basic "dummy proofing" for those chrooting/jailing their tor exit nodes.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Orum0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/362Tor crashes after numerous failed name resolutions.2020-06-13T13:57:13ZTracTor crashes after numerous failed name resolutions.If a tor exit node is unable to contact a DNS server, after numerous failed name resolution
attempts, tor will crash.
gdb(1) seems to always point to the FreeBSD pthread library when asking "where" post-mortem.
Apologies for not having ...If a tor exit node is unable to contact a DNS server, after numerous failed name resolution
attempts, tor will crash.
gdb(1) seems to always point to the FreeBSD pthread library when asking "where" post-mortem.
Apologies for not having the exact output, as I have fixed the issue and no longer have the
core (and would like to not break it again).
However, should you be confirming this, the easiest way to replicate this is by setting up a
tor exit node with a relatively unrestricted exit policy (the default should do). Make sure
that tor does *not* query a valid nameserver by modifying your /etc/resolv.conf (easiest way
to do this without breaking DNS on the host machine is to run tor in a chroot(8) or jail(8)
environment) to point to an invalid nameserver. After a few hours (maybe less on high band-
width nodes) tor will crash, dropping it's core.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Orum