Why Does Firefox Use e4 and e5 Values to Fill Memory?
1 min read

Why Does Firefox Use e4 and e5 Values to Fill Memory?

I was once talking to some colleagues about a Firefox crash bug. As we gazed at the crash report, one leaned over and pointed at the value in one of the CPU registers: 0xe5e5e5e9. “Freed memory,” he sagely indicated: “e5”.

Magic debug numbers

Using special numbers to indicate something in memory is an old trick. Wikipedia even has Wikipedia even has famous examples of such things! Neato! These numbers are often referred to as “poison” or “junk” in the context of filling memory (because they’re supposed to cause the program to fail, or be meaningless garbage).

Mozilla uses this trick (and the “poison” terminology) in Firefox debug builds to indicate uninitialized memory (e4), as well as freed memory (e5). Thus the presence of these values in a crash report, or other failure report, indicate that something has gone wrong with memory handling. But why e4 and e5?


jemalloc is a general purpose implementation of malloc. Firefox utilizes a modified version of jemalloc to perform memory allocation. There's a pretty rich history here, and it would take another blog post to cover how and why Mozilla use jemalloc. So I'm going to hand wave and say that it is used, and the reasons for doing so are reasonable.

jemalloc can use magic/poison/junk values when performing malloc or free. However, jemalloc will use the value a5 when allocating, and 5a when freeing, so why do we see something different in Firefox?

A different kind of poison

When using poison values, it's possible for the memory with these values to still be used. The hope is that when doing so the program will crash and you can see which memory is poisoned. However, with the 5a value in Firefox there was concern that 1) the program would not crash, and 2) as a result, it could be exploited: see this bug.

As a result of these concerns, it was decided to use the poison values we see today. The code that sets these values has undergone some changes since the above bug, but the same values are used. If you want to take a look at the code responsible here is a good place to start.