2

Given code that hasn't been touched for two years, and that never saw such a problem before, is there any explanation for this stack trace:

at java.lang.Thread.run(Thread.java:818)\nCaused by: java.lang.NullPointerException
at xxx.Whatever.foo(Whatever.java:1195)
at xxx.Whatever.bar(Whatever.java:1182)

And line 1182 within that class, in the bar() method:

foo(someArguments)

And line 1195 within that class, in the foo() method:

 if (typeContainer != null && typeContainer.getEnumConstant() == TypeEnum.SOME_TYPE)

I do not understand how this NPE stacktrace is possible. That line above can not throw an NPE.

So, are there any reasonable explanations what is going on here?

Note: "of course" the NPE can't be reproduced. When I run the corresponding test against the system that gave that stacktrace (during a functional test 4 weeks ago), there is no NPE, and the test gives the expected result.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • How certain are you that the code didn't change between when the NPE occured and when you looked at it/ the test worked? – kutschkem Jun 08 '22 at 07:17
  • 4
    This stuff is running in a Thread? Does another thread have access to `typeContainer` so that it can be set to `null` concurrently after the check against `null` passed? – UniversE Jun 08 '22 at 07:18
  • @kutschkem Git tells me that the code was written and released like this 2 years ago, and not touched since then. – GhostCat Jun 08 '22 at 07:55
  • @UniversE Multithreading shouldn't matter. The underlying operation creates a new entity in our system, and that entity isn't visible to other code until it was fully created. Beyond that, that type container is a key "immutable" property of that entity. Meaning: once that property is not null, it can't ever change back to null. – GhostCat Jun 08 '22 at 07:57
  • 2
    Perhaps you had faulty memory when the NPE occurred. As far as I know, this can happen, but would be quite rare. This would also explain that it is the first time it happened in 2 years as well as that is not reproducible – XtremeBaumer Jun 08 '22 at 08:37
  • 1
    Really struggling to get my head around this. If the querent were someone other than GhostCat, I might dismiss this without giving it much thought. But this is just too weird. I don't suppose there are any other methods that can change the value of `typeContainer` in an unexpected way? – Dawood ibn Kareem Jun 10 '22 at 09:26
  • No, it is a local variable, referencing a property of that entity that is about to be created. Even if that property magically turned null, `typeContainer` would still point to the not null object. – GhostCat Jun 10 '22 at 09:49
  • Which JVM version was it? If I recall correctly, the JLS doesn't – or at least, with some versions, didn't – guarantee left-to-right evaluation of conditions inside an `if` statement. In practice, many JVM implementations did follow left-to-right, but it wasn't explicit in JLS. So it's a bit of a guess, but perhaps you're using a JVM where right-to-left evaluation happened? – Kaan Jun 10 '22 at 21:51
  • At least as far back as 6, [JLS (15.23)](https://docs.oracle.com/javase/specs/jls/se6/html/expressions.html#5247) is pretty clear about this: left-hand operand first, right-hand operand only if left-hand was true. So that's probably not what's going on here. – Kaan Jun 10 '22 at 22:21
  • @DawoodibnKareem In the end, luckily, user error, sort of. – GhostCat Jul 18 '22 at 12:10

1 Answers1

0

It turns out: that specific system that showed this error was running in invalid code load. It looks like the system wasn't updated for many months, and on the other hand small "private" fixes were installed, thus leading to an invalid code level.

Thus the most likely explanation is: that code on the system is missing the check for some reason.

GhostCat
  • 137,827
  • 25
  • 176
  • 248