System.NullReferenceException

0
0

We have an app deployed to a dev server that throws the attached error sometimes.

It’s inconsistent, but happens fairly consistently during the day, when the server is busy.  I can’t seem to get it to occur at all later in the day when the server is less busy.  I’m not sure if that’s related or just a coincidence, but I figured it was worth mentioning.

The error message translates to: “Reference to undefined object by an instance an object”

If I run the app with Visual Studio and set it to break on System.NullReferenceException, then I get a similar stack trace, at the same point in the app, but even more inconsistently.  Like I have to run it 10 times or more to get the error once.  The stack trace doesn’t contain any of our functions, only WiseJ function calls.

I’ve tried stepping through our code to see what we’re calling that ultimately triggers it, but it happens so inconsistently, that I haven’t been able to trigger the error when I try.

Any hints on how to track this down?  I might be able to give one of you guys access to the source code, if you want to take a direct look at it.

Attachment
  • David
    • David
    • Jun 6, 2017 - 9:50 pm
    BTW, this happens with 1.3.65 and 1.3.69. I’m not sure about older releases.
  • You must to post comments
0
0

I can’t reproduce the same behavior in 1.3.71.  Did it include a specific fix, or am I likely just not running into it because of thread timings?

  • Luca (ITG)
    There is an additional check on the current theme access. The only place we could find where it can fire a null exception while in Control.RenderStyles () is if the control is being rendered by an out-of-bound thread without a context, which can happen if you call Application.Update() using a control that is disposed by another thread. It’s very hard to reproduce. Can you please check the second thread you mentioned and if it calls Application.Update() and where?
  • You must to post comments
0
0

Excellent!  Thanks.

  • You must to post comments
0
0

I have seen this occasionally when a component is disposed by an out-of-bound thread while it’s being rendered back to the client (or viceversa). We are putting some additional checks for this. That’s one of the problems with a real time framework and concurrency. It’s hard to debug because of the multiple threads. The inconsistencies is basically timing between the threads.

We’ll follow up directly with a test build to verify this issue.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.