Date: Mon, 8 Jan 2024 09:34:43 -0800 From: Enji Cooper <yaneurabeya@gmail.com> To: Farhan Khan <farhan@farhan.codes> Cc: freebsd-hackers@freebsd.org Subject: Re: jemalloc_rtree failed assertion error Message-ID: <80D5F142-9A53-4885-9CE3-0E634890B217@gmail.com> In-Reply-To: <5fe4d15c-f976-4a41-ac50-38ce6a25c289@app.fastmail.com> References: <5fe4d15c-f976-4a41-ac50-38ce6a25c289@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-03E380CB-2F6D-4BD1-8342-821A937DE9D2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jan 6, 2024, at 14:48, Farhan Khan <farhan@farhan.codes> wrote: >=20 > =EF=BB=BFHi all, >=20 > I am writing some code on FreeBSD 15.0-CURRENT and getting this error that= I do not understand: >=20 > <jemalloc>: jemalloc_rtree.c:205: Failed assertion: "!dependent || leaf !=3D= NULL" >=20 > In this case, it happens during a realloc() call. This may very well be a b= ug in my code, but the message is unclear to me. I found the section the sec= tion in the code (/usr/src/contrib/jemalloc/src/rtree.c) but without thoroug= hly diving into the malloc() call I do not understand it. The jemalloc(3) ma= n page has a section called "DIAGNOSTIC MESSAGES", but it does not offer man= y details. >=20 > What does this error mean? >=20 > As an aside, I recommend that this is either documented in more detail bec= ause I found several people citing the problem but I did not find an explana= tion. Hi Farhan! I would reach out to the author, Justin Evans about potential improvements i= n terms of the diagnostic message via the jemalloc project GitHub issue trac= ker. Also, taking a stab based on closed issues, it might be that the memory bein= g reallocated is not being managed via jemalloc: https://github.com/jemalloc= /jemalloc/issues/2500 . If the memory is being managed via some custom mallo= c code not in libc/jemalloc (a prime example being python=E2=80=99s default m= emory arena allocator) or is stack memory, the memory will need to be copied= to an address managed via jemalloc using callow/memcpy/etc. Best of luck! -Enji= --Apple-Mail-03E380CB-2F6D-4BD1-8342-821A937DE9D2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr"><br= ></div><div dir=3D"ltr"><blockquote type=3D"cite">On Jan 6, 2024, at 14:48, = Farhan Khan <farhan@farhan.codes> wrote:<br><br></blockquote></div><bl= ockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<span>Hi all,</span><br><sp= an></span><br><span>I am writing some code on FreeBSD 15.0-CURRENT and getti= ng this error that I do not understand:</span><br><span></span><br><span><= ;jemalloc>: jemalloc_rtree.c:205: Failed assertion: "!dependent || leaf != =3D NULL"</span><br><span></span><br><span>In this case, it happens during a= realloc() call. This may very well be a bug in my code, but the message is u= nclear to me. I found the section the section in the code (/usr/src/contrib/= jemalloc/src/rtree.c) but without thoroughly diving into the malloc() call I= do not understand it. The jemalloc(3) man page has a section called "DIAGNO= STIC MESSAGES", but it does not offer many details.</span><br><span></span><= br><span>What does this error mean?</span><br><span></span><br><span>As an a= side, I recommend that this is either documented in more detail because I fo= und several people citing the problem but I did not find an explanation.</sp= an><br></div></blockquote><div><br></div><div>Hi Farhan!</div><div><br></div= >I would reach out to the author, Justin Evans about potential improvements i= n terms of the diagnostic message via the jemalloc project GitHub issue trac= ker.<div><br></div><div>Also, taking a stab based on closed issues, it might= be that the memory being reallocated is not being managed via jemalloc:&nbs= p;<a href=3D"https://github.com/jemalloc/jemalloc/issues/2500">https://githu= b.com/jemalloc/jemalloc/issues/2500</a> . If the memory is being manage= d via some custom malloc code not in libc/jemalloc (a prime example being py= thon=E2=80=99s default memory arena allocator) or is stack memory, the memor= y will need to be copied to an address managed via jemalloc using callow/mem= cpy/etc.</div><div><br></div><div>Best of luck!</div><div>-Enji</div></body>= </html>= --Apple-Mail-03E380CB-2F6D-4BD1-8342-821A937DE9D2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80D5F142-9A53-4885-9CE3-0E634890B217>