1

I recently received a crash log with the following call stack:

> System.DivideByZeroException: Attempted to divide by zero.    at
> System.Math.Log(Double a, Double newBase)

But, from what I can tell from the docs, this exception shouldn't be thrown and I've tried all sorts of inputs in a test program and haven't been able to reproduce this exception. Also, the code calling this function has a limited range of inputs so I think the input values are ok.

I'm wondering if this might be the result of a bad plugin (my program hosts plugins typically written in C++) or some other piece of code leaving a floating point error on the FPU?

Any thoughts on how to prevent or at least protect myself from this?

Update to answer some questions in the comments:

  • This is happening in .NET 4 Client Profile
  • The app is built in Release mode
  • I don't have access to the input values that cause the exception
  • I can't really disable the plugins - this is a music app hosting VST plugins.
  • The exception is extremely rare - I've see it just twice with thousands of users running the app everyday so trying this in vs out of app context won't really help.
  • The newBase parameter is always 10.0 on the call stack where the exception was reported - so the non-epsilon comparison to 1.0 shouldn't be the issue.

Update 2: turns out this customer could reproduce the problem and found it to be related to licensing of one of his plugins. Once the licensing issue was fixed the issue went away. That's a way too mystical for my liking but at this stage I'm just glad he's got a fix. To quote the customer it "eventually crashed every host in different ways".

Brad Robinson
  • 44,114
  • 19
  • 59
  • 88
  • Maybe perform some data-driven tests using the values you _"think...are ok"_ in say a simple stand-alone console app and then again in your existing app. If it doesn't fail in the console app then the finger of blame points to the ecosystem in your original app. Also, are you able to disable your plugins? –  Jun 27 '17 at 05:35
  • It's a weird issue, could you please share details of '.NET framework' version your application target? Could please share specific input number for which you are getting this issue if available? – Mukesh Jun 27 '17 at 05:46
  • According to the [source](http://referencesource.microsoft.com/#mscorlib/system/math.cs,506), the only division in .NET land is `Log(newBase)` which should only return zero for `newBase == 1`, which is guarded against. – Rob Jun 27 '17 at 05:53
  • Well, comparing a double value without an epsilon is the failure. MS should know about this and to me it is a bug – Sir Rufo Jun 27 '17 at 06:27
  • It depends if you are compiling in debug or release mode and version of VS. I've seen cases where debug mode is really a simulation of the CPU floating point and release uses the CPU floating point unit. And I've seen cases where vendors FPU had bugs and patches were added to PC to compensate for the bugs. The seen different results in math results depending on the different combinations. – jdweng Jun 27 '17 at 06:42
  • @SirRufo but `Log(newBase)` would return a non-zero result for any Double-storable epsilon away from `1`. – grek40 Jun 27 '17 at 06:54
  • 3
    https://stackoverflow.com/a/25206025/17034 – Hans Passant Jun 27 '17 at 08:50
  • Thanks for the fast feedback. Updated the original post with more detail to answer raised questions. – Brad Robinson Jun 27 '17 at 09:59
  • 1
    Get a crash dump to settle the matter, that's a bit more informative than a call stack log. Problems you can't reproduce reliably can't be solved. This may require getting in touch with the users where the crash happened. – Jeroen Mostert Jun 28 '17 at 09:23

0 Answers0