Re: tor 0.2.1.24 crashes on Sparc-Solaris10
Am Dienstag 09 März 2010 schrieb Roger Dingledine:
On Tue, Mar 09, 2010 at 08:23:30PM +0100, thomas.hluch...@netcologne.de wrote:
When starting tor it comes up but crashes within one minute.
Try these:
http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz
http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz.asc
Unfortunately this didnt help. But I succeeded in another way meanwhile:
The crashing tor executables were built with gcc. The one who works right now,
is from Your dev tarball, but built with Suns cc plus an interesting CFLAG. I
found some info in the net
(http://developers.sun.com/solaris/articles/manage_core_dump.html):
The Sun Studio C/C++ compiler has the -xmemalign option, which can be used to
adjust the behavior of the UltraSPARC CPU when there are unaligned memory
addresses that can be determined at compile time. The -xmemalign option causes
the compiler to generate additional load/store instructions for unaligned
memory access. However, the -xmemalign option cannot handle unaligned memory
access during runtime. If unaligned memory access happens during runtime, the
developer needs to change the source code.
So I did:
make distclean
export CC=cc
export CFLAGS='-xmemalign'
./configure --enable-threads --prefix=/usr --sysconfdir=/etc
--with-ssl-dir=/usr/local/ssl
/usr/local/bin/make -j 2
here I got some very unusual output:
source='directory.c' object='directory.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
cc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR=\/usr/share\
-DLOCALSTATEDIR=\/usr/var\ -DBINDIR=\/usr/bin\ -I../../src/common
-I/usr/local/ssl/include -xmemalign -g -O -c directory.c
directory.c, line 3231: warning: statement not reached
source='dirserv.c' object='dirserv.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
cc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR=\/usr/share\
-DLOCALSTATEDIR=\/usr/var\ -DBINDIR=\/usr/bin\ -I../../src/common
-I/usr/local/ssl/include -xmemalign -g -O -c dirserv.c
dirserv.c, line 747: warning: identifier redeclared: dirserv_add_extrainfo
current : function(pointer to struct extrainfo_t {struct
signed_descriptor_t {..} cache_info, array[20] of char nickname, unsigned int
bad_sig :1, pointer to char pending_sig, unsigned int pending_sig_len}, pointer
to pointer to const char) returning enum was_router_added_t
{ROUTER_AUTHDIR_REJECTS(-5), ROUTER_NOT_IN_CONSENSUS_OR_NETWORKSTATUS(-4),
ROUTER_NOT_IN_CONSENSUS(-3), ROUTER_WAS_NOT_NEW(-2), ROUTER_BAD_EI(-1),
ROUTER_ADDED_NOTIFY_GENERATOR(0), ROUTER_ADDED_SUCCESSFULLY(1)}
previous: function(pointer to struct extrainfo_t {struct
signed_descriptor_t {..} cache_info, array[20] of char nickname, unsigned int
bad_sig :1, pointer to char pending_sig, unsigned int pending_sig_len}, pointer
to pointer to const char) returning int : dirserv.c, line 64
dirserv.c, line 3254: warning: static function called but not defined:
dirserv_add_extrainfo()
Might this be the reason why a gcc built crashes on Solaris? The executable was
created and runs now without crashing:-)
Thomas
signature.asc
Description: This is a digitally signed message part.
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Wed, Mar 10, 2010 at 3:47 PM, thomas.hluch...@netcologne.de wrote: Am Dienstag 09 März 2010 schrieb Roger Dingledine: On Tue, Mar 09, 2010 at 08:23:30PM +0100, thomas.hluch...@netcologne.de wrote: When starting tor it comes up but crashes within one minute. Try these: http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz.asc Unfortunately this didnt help. But I succeeded in another way meanwhile: The crashing tor executables were built with gcc. The one who works right now, is from Your dev tarball, but built with Suns cc plus an interesting CFLAG. I found some info in the net (http://developers.sun.com/solaris/articles/manage_core_dump.html): The Sun Studio C/C++ compiler has the -xmemalign option, which can be used to adjust the behavior of the UltraSPARC CPU when there are unaligned memory addresses that can be determined at compile time. The -xmemalign option causes the compiler to generate additional load/store instructions for unaligned memory access. However, the -xmemalign option cannot handle unaligned memory access during runtime. If unaligned memory access happens during runtime, the developer needs to change the source code. It would still help a lot if you could get a stack trace to find out where the unaligned memory access happens. We try to only do aligned memory access in our code; if there's somewhere where we're doing unaligned access, I want to find it and fix it. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
tor 0.2.1.24 crashes on Sparc-Solaris10
Hello, I always run a tor node on my Sparc engine which is connected to the net via DSL and always runs without problems. So the 0.2.1.22 did. Now I got the sources of 0.2.1.24 and installed them doing the same commands as I always do. When starting tor it comes up but crashes within one minute. These are some of the infos: r...@tor# uname -a SunOS tor 5.10 Generic_141444-09 sun4u sparc SUNW,Ultra-4 The configure options: ./configure --enable-threads --prefix=/usr --sysconfdir=/etc --with-ssl-dir=/usr/local/ssl r...@tor# ldd /usr/bin/tor libz.so = /usr/lib/libz.so libevent-1.4.so.2 = /usr/lib/libevent-1.4.so.2 libssl.so.0.9.8 = /usr/local/ssl/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 =/usr/local/ssl/lib/libcrypto.so.0.9.8 libnsl.so.1 = /lib/libnsl.so.1 libsocket.so.1 =/lib/libsocket.so.1 libc.so.1 = /lib/libc.so.1 librt.so.1 =/lib/librt.so.1 libresolv.so.2 =/lib/libresolv.so.2 libdl.so.1 =/lib/libdl.so.1 libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1 libmp.so.2 =/lib/libmp.so.2 libmd.so.1 =/lib/libmd.so.1 libscf.so.1 = /lib/libscf.so.1 libaio.so.1 = /lib/libaio.so.1 libdoor.so.1 = /lib/libdoor.so.1 libuutil.so.1 = /lib/libuutil.so.1 libgen.so.1 = /lib/libgen.so.1 libm.so.2 = /lib/libm.so.2 /platform/SUNW,Ultra-4/lib/libc_psr.so.1 /platform/SUNW,Ultra-4/lib/libmd_psr.so.1 The crash causes no message in notices.log. It looks like: Mar 09 20:07:27.087 [notice] Tor 0.2.1.24 opening log file. Mar 09 20:07:27.092 [notice] Parsing GEOIP file. Mar 09 20:07:28.997 [notice] OpenSSL OpenSSL 0.9.8l 5 Nov 2009 looks like version 0.9.8l; I will try SSL3_FLAGS to enable renegotation. Mar 09 20:07:32.541 [notice] Your Tor server's identity key fingerprint is 'herecomesthesun E959DE5174DE719D712E181704DF20E7D47FD221' Mar 09 20:08:03.318 [notice] We now have enough directory information to build circuits. Mar 09 20:08:03.318 [notice] Bootstrapped 80%: Connecting to the Tor network. Mar 09 20:08:04.474 [notice] Guessed our IP address as 89.0.140.247 (source: 194.109.206.212). Mar 09 20:08:05.699 [notice] Bootstrapped 85%: Finishing handshake with first hop. Mar 09 20:08:06.808 [notice] Bootstrapped 90%: Establishing a Tor circuit. Mar 09 20:08:08.891 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Mar 09 20:08:08.895 [notice] Bootstrapped 100%: Done. Mar 09 20:08:08.895 [notice] Now checking whether ORPort 89.0.140.247:9001 and DirPort 89.0.140.247:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Mar 09 20:08:14.977 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Mar 09 20:08:15.846 [notice] Tor 0.2.1.24 opening log file. Mar 09 20:08:15.851 [notice] Parsing GEOIP file. At Mar 09 20:08:14.977 a new tor process started after the crash of the old process. This is because it starts vis SMF Service Manifest instead of initscript. I did a truss -p pid_of_tor to see better whats going on. It looks like: /1: write(14, M a r 0 9 2 0 : 1 0.., 127)= 127 /1: time() = 1268161838 /1: port_associate(3, 4, 0x0012, 0x0001, 0x) = 0 /1: port_getn(3, 0xFFBFFB20, 8, 1, 0xFFBFFB14) = 1 [0] /1: clock_gettime(4, 0xFFBFFBA4)= 0 /1: write(14, M a r 0 9 2 0 : 1 0.., 75) = 75 /1: write(14, M a r 0 9 2 0 : 1 0.., 125)= 125 /1: read(18, 170301\0 , 5) = 5 /1: read(18, V -87 ~ jDA9BB8 P s90D7.., 32) = 32 /1: read(18, 17030102 , 5) = 5 /1: read(18, D0A7AB p80 4 - d yB4BF z.., 544) = 544 /1: write(14, M a r 0 9 2 0 : 1 0.., 97) = 97 /1: write(14, M a r 0 9 2 0 : 1 0.., 129)= 129 /1: time() = 1268161838 /1: time() = 1268161838 /1: time() = 1268161838 /1: port_associate(3, 4, 0x0016, 0x0005, 0x) = 0 /1: write(14, M a r 0 9 2 0 : 1 0.., 90) = 90 /1: write(14, M a r 0 9 2 0 : 1 0.., 127)= 127 /1: time() = 1268161838 /1: port_associate(3, 4, 0x0012, 0x0001, 0x) = 0 /1: port_getn(3, 0xFFBFFB20, 8, 1, 0xFFBFFB14) = 1 [0] /1: clock_gettime(4, 0xFFBFFBA4)= 0 /1: write(14, M a r 0 9 2 0 : 1 0.., 77) = 77 /1: send(22, 02\0\0\0\0\0\0\014 \r '.., 197, 0) = 197 /1: time() =
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Tue, Mar 09, 2010 at 08:23:30PM +0100, thomas.hluch...@netcologne.de wrote: I always run a tor node on my Sparc engine which is connected to the net via DSL and always runs without problems. So the 0.2.1.22 did. Now I got the sources of 0.2.1.24 and installed them doing the same commands as I always do. When starting tor it comes up but crashes within one minute. Try these: http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz.asc It includes: o Major bugfixes: - Fix a regression from our patch for bug 1244 that caused relays to guess their IP address incorrectly if they didn't set Address in their torrc and/or their address fails to resolve. Bugfix on 0.2.1.23; fixes bug 1269. I guess that bug could conceivably cause a crash on an overzealous compiler. I'm waiting for the fix to get some testing in 0.2.2.10-alpha before putting out the new stable. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Tue, Mar 9, 2010 at 2:23 PM, thomas.hluch...@netcologne.de wrote: [...] Any ideas, any help? Can you get a stack trace? That's usually the best way to start debugging a crash. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
