<![CDATA[i have seen true evil.]]>i have seen true evil. yes.

mozilla firefox has a custom allocator that redefines/macros a bunch of malloc/free calls. it does this to intercept them, calling the real (system) allocator sparingly in large chunks, and its own for small allocations. useful for optimising lots of small allocations.

the code doesn't match obsd. llvm 19 was ok, 20+ is stricter. re-trying librewolf 149 build on obsd current, wiith llvm 19... otherwise i'll just build with --disable-jemalloc (i want to avoid that)

Link Preview Image
]]>https://board.circlewithadot.net/topic/39d7c63f-047c-473d-9397-48d3beb854b1/i-have-seen-true-evil.RSS for NodeFri, 17 Apr 2026 19:45:47 GMTMon, 13 Apr 2026 16:53:38 GMT60<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 21:55:43 GMT]]>@libreleah it's using syscalls implemented by the kernel (mmap and/or brk probably), but those aren't what firefox is reimplementing

whatever firefox is doing does seem to break LD_PRELOADing another allocator, which is annoying. when I tried LD_PRELOADing mimalloc globally on alpine it broke audio/video playback]]>https://board.circlewithadot.net/post/https://berkeley.edu.pl/objects/87b3b710-4490-49c7-98ff-e2aa5cb690eahttps://board.circlewithadot.net/post/https://berkeley.edu.pl/objects/87b3b710-4490-49c7-98ff-e2aa5cb690eaMon, 13 Apr 2026 21:55:43 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 21:44:00 GMT]]>@noisytoot how asinine. yes, technically you are correct, but what, pray tell, implements said allocator that malloc returns pointers from?

]]>https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116399580145035456https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116399580145035456Mon, 13 Apr 2026 21:44:00 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 19:41:52 GMT]]>@libreleah malloc isn't a kernel function, it's part of libc]]>https://board.circlewithadot.net/post/https://berkeley.edu.pl/objects/767669aa-e6d4-4e2e-9793-d542bbb32742https://board.circlewithadot.net/post/https://berkeley.edu.pl/objects/767669aa-e6d4-4e2e-9793-d542bbb32742Mon, 13 Apr 2026 19:41:52 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 18:26:25 GMT]]>fuck u mozilla

--- memory/build/mozjemalloc.cpp.orig
+++ memory/build/mozjemalloc.cpp
@@ -5257,7 +5257,7 @@ static void replace_malloc_init_funcs(malloc_table_t* table) {


NOTHROW_MALLOC_DECL(...) \
- MOZ_MEMORY_API MACRO_CALL(GENERIC_MALLOC_DECL, (noexcept(true), __VA_ARGS__))
+ MOZ_MEMORY_API MACRO_CALL(GENERIC_MALLOC_DECL, (, __VA_ARGS__))

u will not defeat me mozilla

]]>https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398803190278010https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398803190278010Mon, 13 Apr 2026 18:26:25 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 18:21:22 GMT]]>@libreleah
Aaaaaaaaaaa

]]>https://board.circlewithadot.net/post/https://mstdn.social/users/ozzelot/statuses/116398783349316636https://board.circlewithadot.net/post/https://mstdn.social/users/ozzelot/statuses/116398783349316636Mon, 13 Apr 2026 18:21:22 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 17:21:17 GMT]]>@TheLancashireman i mean, i wrap malloc in my programs too (mostly to check nulls and such - and i wrap free and make it set a pointer to null after freeing - and my malloc wrapper will err if being given a pointer that isn't null).

but directly redefining functions, yeah, that's evil.

]]>https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398547080053401https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398547080053401Mon, 13 Apr 2026 17:21:17 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 17:14:39 GMT]]>@libreleah

There are some interesting edge cases where redefining malloc etc. is useful. Imagine a safety process that has specific requirements like near-constant time, no chance of a failure to allocate, etc.

But I wouldn't say a browser falls into that category ...

]]>https://board.circlewithadot.net/post/https://hostux.social/users/TheLancashireman/statuses/116398521006859432https://board.circlewithadot.net/post/https://hostux.social/users/TheLancashireman/statuses/116398521006859432Mon, 13 Apr 2026 17:14:39 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 17:14:37 GMT]]>@libreleah Well, I guess I should have looked at your librewolf WIP before commenting

]]>https://board.circlewithadot.net/post/https://bsd.network/users/vlkrs/statuses/116398520884193045https://board.circlewithadot.net/post/https://bsd.network/users/vlkrs/statuses/116398520884193045Mon, 13 Apr 2026 17:14:37 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 17:10:03 GMT]]>@vlkrs yeah, no idea why firefox builds on current. (though i didn't test-build that)

have a look here: https://codeberg.org/vimuser/librewolf-openbsd-port

i removed use of www/mozilla and put everything in one place. standalone port.

builds fine with llvm 19 on openbsd 7.8, when you use my stable-7.8 branch (uses librewolf 143)

149 (master branch on my port repo) needs some work. i'm rebuilding with

MODCLANG_VERSION = 19

hopefully that'll fix it for now. and either i, or upstream, will fix mozilla's allocator later.

]]>https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398502967962354https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398502967962354Mon, 13 Apr 2026 17:10:03 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 17:07:34 GMT]]>@libreleah I didn't look deeply into librewolf, but firefox 149.0.2 hums along nicely on -current here, why not base your work on the existing port?

]]>https://board.circlewithadot.net/post/https://bsd.network/users/vlkrs/statuses/116398493192909486https://board.circlewithadot.net/post/https://bsd.network/users/vlkrs/statuses/116398493192909486Mon, 13 Apr 2026 17:07:34 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 17:05:28 GMT]]>here's a thought: maybe *DON'T* redeclare kernel functions in your codebase? if you're having to write your own allocator, then you are hacking around a much deeper problem. but this is mozilla. anything is possible.

]]>https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398484928755244https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398484928755244Mon, 13 Apr 2026 17:05:28 GMT<![CDATA[Reply to i have seen true evil. on Mon, 13 Apr 2026 16:57:18 GMT]]>i *will* have librewolf 149 compiling, TONIGHT, on openbsd -CURRENT

if building with llvm 19 still dosen't work, i'm going to gut mozilla's allocator myself, fixing all the declarations by hand.

using the system allocator directly (no intercept functions) is possible using --disable-jemalloc in ./configure, when building mozilla code. but that means using openbsd's... slow allocator, for every allocation. and that would make the javascript engine slow as molasses.

mozilla firefox is a sin.

]]>https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398452771653098https://board.circlewithadot.net/post/https://mas.to/users/libreleah/statuses/116398452771653098Mon, 13 Apr 2026 16:57:18 GMT