Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Wed, Mar 10, 2010 at 3:47 PM, 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/
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 Tue, Mar 9, 2010 at 2:23 PM, 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/
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/
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 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()