Date: Tue, 8 May 2012 15:59:42 -0700 From: Jason Evans <jasone@FreeBSD.org> To: Stefan Farfeleder <stefanf@FreeBSD.org> Cc: Steve Wills <swills@FreeBSD.org>, current@FreeBSD.org Subject: Re: <jemalloc>: jemalloc_arena.c:182: Failed assertion: "p[i] == 0" Message-ID: <93A2687F-5061-42B7-883B-F92371F8023F@FreeBSD.org> In-Reply-To: <20120508215802.GB1410@mole.fafoe.narf.at> References: <20120421185402.GH1743@albert.catwhisker.org> <7AD8956D-AD18-4CAB-9953-06E00185A7DA@freebsd.org> <a457b78de070b45bbffdd06271c6a7ef.squirrel@mouf.net> <A67012C5-E54A-4F60-A1DD-AAFB3867793B@FreeBSD.org> <4FA94E51.8020902@FreeBSD.org> <20120508213717.GA1410@mole.fafoe.narf.at> <EBD45BFC-D4A4-4B29-B946-5C67357FC2CD@FreeBSD.org> <20120508215802.GB1410@mole.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote: > On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote: >> On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote: >>> On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote: >>>> On 05/08/12 00:46, Jason Evans wrote: >>>>>=20 >>>>> How recent is your system? This problem should have been fixed by >>>>> r234569, so if you're still seeing problems after that revision, >>>>> there's another problem we need to figure out. (By the way, it's >>>>> possible for an application to trigger this assertion, but >>>>> unlikely.) >>>>>=20 >>>>=20 >>>> My system is r235115. >>>=20 >>> I hit the same assertion with r235052 and inkscape. I'm now using >>> MALLOC_PRODUCTION and it works again. >>=20 >> Was the assertion failure easily reproducible with inkscape? >=20 > Yes, it crashed everytime before showing the GUI. The backtrace goes > like this: >=20 > (gdb) bt > #0 0x000000080ad760ac in thr_kill () from /lib/libc.so.7 > #1 0x000000080ae22548 in abort () from /lib/libc.so.7 > #2 0x000000080ad9f57d in sbrk () from /lib/libc.so.7 > #3 0x000000080ada1c51 in sbrk () from /lib/libc.so.7 > #4 0x000000080ada3624 in sbrk () from /lib/libc.so.7 > #5 0x000000080ada3ffc in sbrk () from /lib/libc.so.7 > #6 0x000000080ada432d in sbrk () from /lib/libc.so.7 > #7 0x000000080ad9394f in syscall () from /lib/libc.so.7 > #8 0x000000080ad93d70 in syscall () from /lib/libc.so.7 > #9 0x000000080ada73a0 in malloc () from /lib/libc.so.7 > #10 0x000000080a6a283d in operator new () from /usr/lib/libstdc++.so.6 > #11 0x00000000007af660 in = sigc::internal::typed_slot_rep<sigc::bind_functor<-1, = sigc::pointer_functor3<SPObject*, SPObject*, SPStyle*, void>, SPStyle*, = sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> >::dup = () > #12 0x00000008033016b4 in sigc::slot_base::slot_base () > from /usr/local/lib/libsigc-2.0.so.0 > #13 0x00000000006f0a77 in std::list<sigc::slot_base, = std::allocator<sigc::slot_base> >::insert () > #14 0x000000080330084a in sigc::internal::signal_impl::insert () > from /usr/local/lib/libsigc-2.0.so.0 > #15 0x0000000803300893 in sigc::internal::signal_impl::connect () > from /usr/local/lib/libsigc-2.0.so.0 > #16 0x0000000803300a44 in sigc::signal_base::connect () > #17 0x00000000007a8635 in SPIPaint::read () > [=85] sbrk() is being used rather than mmap(). Unless mmap() is failing = (which would surprise me), this indicates that you are using a version = of libc that's old enough to have the bug I fixed in r234569. Thanks, Jason=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93A2687F-5061-42B7-883B-F92371F8023F>