Hi Jake, (ccing maintainers, hope thats ok)
Am 09.08.2016 um 23:02 schrieb jgoerzen <[email protected]>: > I need some help debugging a segmentation fault in the latest release of > tor. The core file for this program is on the buildfarm here: > > /home/jgoerzen/opencsw/tor/trunk/core > > If you have time would you have a look at it? I tried using mdb to debug > it but I don't know enough c or assembler to figure out what is going wrong. > Here is what I found running the program with mdb: > > jgoerzen@unstable10x [global]:/home/jgoerzen/opencsw/tor/trunk > mdb > work/solaris10-i386/build-isa-pentium_pro/tor-0.2.8.6/src/or/tor > > > ::run > Aug 09 22:00:08.507 [notice] Tor v0.2.8.6 (git-b54676641111fea6) running on > SunOS with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. > Aug 09 22:00:08.508 [notice] Tor can't help you if you use it wrong! Learn > how to be safe at https://www.torproject.org/download/download#warning > Aug 09 22:00:08.509 [notice] Configuration file "/etc/opt/csw/tor/torrc" not > present, using reasonable defaults. > Aug 09 22:00:08.512 [notice] Opening Socks listener on 127.0.0.1:9050 > mdb: stop on SIGSEGV > mdb: target stopped at: > libc.so.1`strlen+0xc: movl (%eax),%edx > mdb: You've got symbols! > Loading modules: [ ld.so.1 libc.so.1 ] > > ::stack > libc.so.1`strlen+0xc(822dc20, 8047588, 8047450, 0) > libc.so.1`vsnprintf+0x73(804749c, 80, 822dc0a, 8047588, 0, fee95b38) > tor_vasprintf+0x63(82d5138, 822dc0a, 8047588, fee41afc, 8282f08, 82d43c0) > tor_asprintf+0x40(82d5138, 822dc0a, 0, 2346, 0, 0) > dir_server_new+0x288(0, 2346, 2329, 0, 80476e8, 0) > fallback_dir_server_new+0x66(80476bc, 2346, 2329, 0, 80476e8, 0) > parse_dir_fallback_line+0x4c3(82d25f8, 1, 0, 8229a88, 82d25f8, 8282f08) > set_options+0x2475(82d25f8, 8047894, 0, 0, 0, 8047894) > options_init_from_string+0x392(82bbc68, 82bbc78, 0, 0, 8047894, 0) > options_init_from_torrc+0x20f(1, 8047bc8, 820cca8, 8237cc0, 82bc030, 8227dc2) > tor_init+0x380(1, 8047bc8, 8060c30, 8047b80, 0, 0) > tor_main+0x6b(1, 8047bc8, fefc2ab4, feefdeb5, fee73721, 29) > main+0x36(1, 8047bc8, 8047bd0) > _start+0x80(1, 8047cc8, 0, 8047ccc, 8047cd6, 8047ce9) > > It looks like it crashes in strlen. So lets see what string it operates on: > 0x822dc20/S 0x822dc20: :%d > 0x822dc20/4B 0x822dc20: 3a 25 64 0 This looks good. Now what does strlen do? > strlen::dis libc.so.1`strlen: movl 0x4(%esp),%eax # Copy arg to register libc.so.1`strlen+4: testl $0x3,%eax # adress % 4 == 0 ? libc.so.1`strlen+9: jne +0x28 <libc.so.1`strlen+0x31> # No, jump libc.so.1`strlen+0xb: nop libc.so.1`strlen+0xc: movl (%eax),%edx libc.so.1`strlen+0xe: movl $0x7f7f7f7f,%ecx libc.so.1`strlen+0x13: andl %edx,%ecx libc.so.1`strlen+0x15: addl $0x4,%eax libc.so.1`strlen+0x18: addl $0x7f7f7f7f,%ecx libc.so.1`strlen+0x1e: orl %edx,%ecx libc.so.1`strlen+0x20: andl $0x80808080,%ecx libc.so.1`strlen+0x26: cmpl $0x80808080,%ecx libc.so.1`strlen+0x2c: je -0x20 <libc.so.1`strlen+0xc> libc.so.1`strlen+0x2e: subl $0x4,%eax libc.so.1`strlen+0x31: cmpb $0x0,(%eax) # is the byte zero? libc.so.1`strlen+0x34: je +0xc <libc.so.1`strlen+0x40> libc.so.1`strlen+0x36: incl %eax libc.so.1`strlen+0x37: testl $0x3,%eax libc.so.1`strlen+0x3c: jne -0xb <libc.so.1`strlen+0x31> libc.so.1`strlen+0x3e: jmp -0x32 <libc.so.1`strlen+0xc> libc.so.1`strlen+0x40: subl 0x4(%esp),%eax libc.so.1`strlen+0x44: ret This looks like a modern implementation than the usual size_t strlen(const char *s) { const char *s0 = s + 1; while (*s++ != '\0‘) ; return (s - s0); } and pretty similar to http://cr.illumos.org/~webrev/tsoome/loader_import/usr/src/boot/lib/libc/string/strlen.c.html So we have SIGSEGV at strlen+0xc, that is an indirect load from %eax, and eax is > ::regs %cs = 0x003b %eax = 0x00000000 … Trying to read from address 0. This now is strange as 0x822dc20 was passed in to strlen. When using lib0@0 there is a related error in tor_asprintf shown, maybe this leads you closed to the bug: dam@unstable10x [global]:/home/dam > LD_PRELOAD_32=/usr/lib/[email protected] /home/jgoerzen/opencsw/tor/trunk/work/solaris10-i386/build-isa-pentium_pro/tor-0.2.8.6/src/or/tor Aug 10 16:56:43.295 [notice] Tor v0.2.8.6 (git-b54676641111fea6) running on SunOS with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Aug 10 16:56:43.295 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Aug 10 16:56:43.339 [notice] Configuration file "/etc/opt/csw/tor/torrc" not present, using reasonable defaults. Aug 10 16:56:43.347 [notice] Opening Socks listener on 127.0.0.1:9050 Aug 10 16:56:43.000 [err] tor_asprintf(): Bug: Internal error in asprintf (on Tor 0.2.8.6 b54676641111fea6) Aug 10 16:56:43.000 [err] tor_assertion_failed_(): Bug: src/common/compat.c:529: tor_asprintf: Assertion 0 failed; aborting. (on Tor 0.2.8.6 b54676641111fea6) Aug 10 16:56:43.000 [err] Bug: Assertion 0 failed in tor_asprintf at src/common/compat.c:529. (Stack trace not available) (on Tor 0.2.8.6 b54676641111fea6) At the moment I don’t have a smart idea and would need some more debugging, but for today I am out of time, sorry. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
signature.asc
Description: Message signed with OpenPGP using GPGMail
