C Which library uses 0x5a5a5a5a5a5a5a5a as a placeholder for an invalid pointer?

cracauer@

Developer
I have a gtk/glib using open source program (jackd-jamin-gtk2) that recently started segfaulting with no changes to the program. Must be some library cracking down on undefined use or something.

The segfault is in a glib linked list, with both pointers in first list cell being 0x5a5a5a5a5a5a5a5a.

This is obviously a marker for "invalid pointer", but who uses it? I grepped both the application and glib sources and they aren't it. Does this ring a bell with anyone?
 
I'm not sure, but it's the same sentinal value every crash, not a random thing?

Not random at all. In fact this same value appears in both Linux and FreeBSD. That is why I originally assumed a new glib did it.
 
Not random at all. In fact this same value appears in both Linux and FreeBSD. That is why I originally assumed a new glib did it.

I misremembered. Linux has other values (but the same segfault).

So jemalloc as the user of this value is plausible.
 
  • Like
Reactions: mer
opt.junk (const char *) r- [--enable-fill]
Junk filling. If set to “alloc”, each byte of uninitialized
allocated memory will be initialized to 0xa5. If set to “free”, all
deallocated memory will be initialized to 0x5a. If set to “true”,
both allocated and deallocated memory will be initialized, and if
set to “false”, junk filling be disabled entirely. This is intended
for debugging and will impact performance negatively. This option
is “false” by default unless --enable-debug is specified during
configuration, in which case it is “true” by default.
 
opt.junk (const char *) r- [--enable-fill]
Junk filling. If set to “alloc”, each byte of uninitialized
allocated memory will be initialized to 0xa5. If set to “free”, all
deallocated memory will be initialized to 0x5a. If set to “true”,
both allocated and deallocated memory will be initialized, and if
set to “false”, junk filling be disabled entirely. This is intended
for debugging and will impact performance negatively. This option
is “false” by default unless --enable-debug is specified during
configuration, in which case it is “true” by default.

That leaves the question of whether I am looking at memory never initialized after alloc or used after free.
 
this shows us that programs are not really tested :)
how to you hide a thread from rust advocates ?

it's a5 for no init and 5a after free
so we know
 
if its jemalloc its use after free according to manpage
I had to disable jemalloc on a C++ project a couple months ago on Linux: -DNOJEM=1

I don't remember the specific error or if it was something like GCC vs Clang, but it seemed unique to the distro and unexpected (built fine for years no problem with jemalloc)
 
Back
Top