Date: Fri, 8 Jul 2011 15:47:08 +0400 From: KOT MATPOCKuH <matpockuh@gmail.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: Doug Barton <dougb@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP Message-ID: <CALmdT0V_MG7abrGyp-JodsP3Bun-C863VGqTkSAdewnFbiA-%2Bg@mail.gmail.com> In-Reply-To: <20110707154958.GK14797@alchemy.franken.de> References: <BANLkTinMimzfdK0Y4otZegGvztwo-yA4EA@mail.gmail.com> <BANLkTi=_PP=tvLUbXiTE1DT4tMirLRUY%2Bw@mail.gmail.com> <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <CALmdT0V2Fzf8mcYRzYzsu5XkauuxGaF4dxFPR7ZHr-FH2a_5bQ@mail.gmail.com> <20110707100446.GJ14797@alchemy.franken.de> <CALmdT0VFC7kBxaEqLuFVWkLk3o2hLe29tsx3dgn17tuTNaTRLA@mail.gmail.com> <20110707154958.GK14797@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/7/7 Marius Strobl <marius@alchemy.franken.de>: > That's not the patch I was referring to. I did a second one which just > entirely disables the use of atomic operations on sparc64: > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff Omg. I'm sorry. I applied this patch and restarted named, but named crashed immediatly after start: 08-Jul-2011 15:29:54.631 found 2 CPUs, using 2 worker threads 08-Jul-2011 15:29:54.633 using up to 4096 sockets Segmentation fault (core dumped) core's backtrace: #0 0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7 (gdb) bt #0 0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7 #1 0x0000000040953ccc in __sparc_utrap_install () from /lib/libc.so.7 #2 0x0000000040953f70 in __sparc_utrap_install () from /lib/libc.so.7 #3 0x00000000409537ac in __sparc_utrap_install () from /lib/libc.so.7 #4 0x00000000407c2d54 in pthread_mutex_lock () from /lib/libthr.so.3 #5 0x0000000000228dcc in ?? () Previous frame identical to this frame (corrupt stack?) Could this be a sign to a problem in libthr? PS. Also one month ago I got a problems with another multithreaded application from ports (www/oops). oops was crashed with stack's backtrace: #0 0x0000000040d8fc88 in __sparc_utrap_install () from /lib/libc.so.7 #1 0x0000000040d8fdac in __sparc_utrap_install () from /lib/libc.so.7 #2 0x0000000040d90050 in __sparc_utrap_install () from /lib/libc.so.7 #3 0x0000000040d8f88c in __sparc_utrap_install () from /lib/libc.so.7 #4 0x0000000040d64044 in _malloc_thread_cleanup () from /lib/libc.so.7 #5 0x0000000040c039b8 in fork () from /lib/libthr.so.3 #6 0x0000000040c03d38 in fork () from /lib/libthr.so.3 #7 0x0000000040c03f50 in pthread_exit () from /lib/libthr.so.3 #8 0x0000000040c04414 in pthread_detach () from /lib/libthr.so.3 #9 0x0000000040c04710 in pthread_create () from /lib/libthr.so.3 But on yesterday's world's build oops works properly. I think it may be related to r223228 (?) Or I incorrectly analyze stack for multithreaded applications? -- MATPOCKuH
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALmdT0V_MG7abrGyp-JodsP3Bun-C863VGqTkSAdewnFbiA-%2Bg>