5 ms·

This is great. Reminds me of a crash I saw early in my career. It was a null-pointer exception, except it occurred right after confirming the address was non-nu

This is great. Reminds me of a crash I saw early in my career. It was a null-pointer exception, except it occurred right after confirming the address was non-null. This was on a single core with a non-preemptible kernel. So the processor just took the wrong branch! There was simply no other explanation.

jrpelkonen 4y ago
Interesting, how did you fix it? Negate the comparison with an appropriate comment?
- ericbarrett 4y ago
  There was no fix! It was a one-off hardware error.
JoeAltmaier 4y ago
Got to read the assembly to really know what happened. E.g. if the architecture has pointers with non-address bits (modes or segments or whatever) and those bits were set yet the rest of the address was 'null', and the check was for 'all bits zero' then you could conceivably get that situation.
mcculley 4y ago
What hardware/platform was this? I worked on AIX on POWER a long time ago and it had to map the zero page read-only just to support speculative execution of dereferencing the NULL pointer, if I remember right. If you were on a platform that did this wrong, speculative execution could have been dereferencing the NULL pointer.
- ericbarrett 4y ago
  It was a DEC Alpha chip, over two decades ago. (Or MIPS?) Pretty sure there was no speculative execution. In any case, the senior engineer I was working with would have known that—getting to "it just did the wrong thing" was our final and least satisfying conclusion!
  - mcculley 4y ago
    The DEC Alpha had speculative execution. I found lots of bugs porting code to it. It was my first 64-bit platform.
    - thewebcount 4y ago
      I found a bug in the compiler on it! I was writing some fractal generating code, and found that something I did caused the compiler to output the error message: “Dave doesn’t think this should compile. Please send an email to dave<someone-or-other>@dec.com”. So I did. They replied that they found the problem and had a fix for it.
  - lmm 4y ago
    The Alpha does quite aggressive instruction reordering, you need to use more memory barriers than x86 in parallel code for example.
Jiro 4y ago
Are you sure the compiler didn't say "since having a null pointer gives undefined behavior, we can optimize out the part that confirms the address is non-null"?
- logicchop 4y ago
  This is likely your answer. C++ story. I worked at a large company that had a "no exceptions" policy and a custom operator new. If a new expression failed it would return nullptr instead of throwing. So lots of people wrote "checking" code to make sure the result wasn't nullptr, except that the compiler would always just elide that code since the standard mandates that the result cannot be nullptr. Many weird crashes ensued.
  - aw1621107 4y ago
    There are non-throwing operator new overloads that can return nullptr, but I'm not sure if those are a relatively recent development. Did the non-throwing operator new overloads not exist at the time?
    - logicchop 4y ago
      Hard to say. Most of the uses probably predated the custom operator new and so nobody thought about it. Not to mention the places you cannot sneak into to switch to std::nothrow.
      - aw1621107 4y ago
        Ah, that's fair. Didn't think of code that couldn't be changed.
    - bregma 4y ago
      `new (nothrow)` was in C++98 and in ARM C++ before that.
      - aw1621107 4y ago

jrpelkonen 4y ago

Interesting, how did you fix it? Negate the comparison with an appropriate comment?

ericbarrett 4y ago
There was no fix! It was a one-off hardware error.

JoeAltmaier 4y ago

Got to read the assembly to really know what happened. E.g. if the architecture has pointers with non-address bits (modes or segments or whatever) and those bits were set yet the rest of the address was 'null', and the check was for 'all bits zero' then you could conceivably get that situation.

mcculley 4y ago

What hardware/platform was this? I worked on AIX on POWER a long time ago and it had to map the zero page read-only just to support speculative execution of dereferencing the NULL pointer, if I remember right. If you were on a platform that did this wrong, speculative execution could have been dereferencing the NULL pointer.

ericbarrett 4y ago
It was a DEC Alpha chip, over two decades ago. (Or MIPS?) Pretty sure there was no speculative execution. In any case, the senior engineer I was working with would have known that—getting to "it just did the wrong thing" was our final and least satisfying conclusion!
- mcculley 4y ago
  The DEC Alpha had speculative execution. I found lots of bugs porting code to it. It was my first 64-bit platform.
  - thewebcount 4y ago
    I found a bug in the compiler on it! I was writing some fractal generating code, and found that something I did caused the compiler to output the error message: “Dave doesn’t think this should compile. Please send an email to dave<someone-or-other>@dec.com”. So I did. They replied that they found the problem and had a fix for it.
- lmm 4y ago
  The Alpha does quite aggressive instruction reordering, you need to use more memory barriers than x86 in parallel code for example.

Jiro 4y ago

Are you sure the compiler didn't say "since having a null pointer gives undefined behavior, we can optimize out the part that confirms the address is non-null"?

logicchop 4y ago
This is likely your answer. C++ story. I worked at a large company that had a "no exceptions" policy and a custom operator new. If a new expression failed it would return nullptr instead of throwing. So lots of people wrote "checking" code to make sure the result wasn't nullptr, except that the compiler would always just elide that code since the standard mandates that the result cannot be nullptr. Many weird crashes ensued.
- aw1621107 4y ago
  There are non-throwing operator new overloads that can return nullptr, but I'm not sure if those are a relatively recent development. Did the non-throwing operator new overloads not exist at the time?
  - logicchop 4y ago
    Hard to say. Most of the uses probably predated the custom operator new and so nobody thought about it. Not to mention the places you cannot sneak into to switch to std::nothrow.
    - aw1621107 4y ago
      Ah, that's fair. Didn't think of code that couldn't be changed.
  - bregma 4y ago
    `new (nothrow)` was in C++98 and in ARM C++ before that.
    - aw1621107 4y ago