Assertion failure from Graphics::strokePath in debug, generates errors during release

General JUCE discussion
1

I’m using AudioVisualizerComponent for an oscilloscope, and a simple FFT graphing component. I’m getting intermittent run time errors, where calling Graphics::strokePath has an assertion failure (both x and y values are NaN). Here’s my stack trace:

#0	0x0000000100284e76 in juce::Path::startNewSubPath(float, float) 
#1	0x00000001002febe3 in juce::PathStrokeHelpers::addSubPath(juce::Path&, juce::Array<juce::PathStrokeHelpers::LineSection, juce::DummyCriticalSection, 0>&, bool, float, float, juce::PathStrokeType::JointStyle, juce::PathStrokeType::EndCapStyle, juce::PathStrokeHelpers::Arrowhead const*) 
#2	0x000000010028c739 in juce::PathStrokeHelpers::createStroke(float, juce::PathStrokeType::JointStyle, juce::PathStrokeType::EndCapStyle, juce::Path&, juce::Path const&, juce::AffineTransform const&, float, juce::PathStrokeHelpers::Arrowhead const*) 
#3	0x000000010028c196 in juce::PathStrokeType::createStrokedPath(juce::Path&, juce::Path const&, juce::AffineTransform const&, float) const
#4	0x0000000100290c22 in juce::Graphics::strokePath(juce::Path const&, juce::PathStrokeType const&, juce::AffineTransform const&) const

I cannot reproduce the assertion failure every time I run my app, it happens about 40% of the time.

When compiling with optimizations I get the following error printed to the console:

<Error>: Error: this application, or a library it uses, has passed an invalid numeric value (NaN, or not-a-number) to CoreGraphics API and this value is being ignored.Please fix this problem.

I have verified that I’m not passing any NaN or Inf values to Path::startNewSubpath or Path::lineTo (the only path functions I’m using). Any suggestions on how to debug this problem, or what might be causing it?

2

That’s pretty strange, if there really aren’t any NaNs in your own values then I guess you could have stumbled on some edge-case numbers that trigger a NaN in the stroke calculation routines. If you can get us some code that reproduces this I could take a look at handling it, but without being able to reproduce it there’s no way we could track it down.

3

If there were NaNs in the path, then an assertion failure would happen before calling strokePath(), right? Either way, I added some code along the lines of jassert ( !(isnan(x)||isnan(y)||isinf(x)||isinf(y)) ) before using lineTo() or startNewSubPath().

The CoreGraphics error however pops up when using just the AudioVisualizerComponent and compiling with the -Os flag, using pushSample on a single channel.

4

Well, it could just be some really large/small numbers that end up generating an out of bounds value. Can you catch it when this happens and dump the path using Path::writePathToStream() so we can debug it?

5

I’ll try and recreate it. It seems like it’s an edge case, because using a simple averaging filter to smooth the points along the path removed the issue.

1 Like
6

btw, I don’t want to go on your nerves jules, we have this argument some time ago, but i still think a proper gui framework should not show a undefined behaviour even when posting infinite-floats to a graphic subroutine. Core-graphics just ignores the values and warns, which is the right thing to do, the software renderer on windows might crash, which is the worst case.
Float values just tend to become NaNs somewhere in edge cases.

7

Sorry, but how is that different from what we’re doing?

The OP isn’t reporting a crash, just an assertion. And IMHO that’s exactly the right behaviour, because as a developer you should be told if you’re feeding garbage into a path, but in a release build your users wouldn’t be affected by this.

8

Sorry for intervening, this is exact issue i was referring to, this code will crash a release build on windows.

float v = (float)1.17549e-038;
v -= 0.1f;
v += 0.1f;
RectangleList<float> rl;
rl.add(-1.f / v, 10.f, 10.f, 1.f / v);
g.fillRectList(rl);

We had an argument about it, that this is so called undefined behaviour, but think even when the coordinate is wrong, it shouldn’t crash a release build

9

If you’ve got a crash then of course we should fix that, but this doesn’t crash for me. Assertion, yes, but no actual crash. Want to give more info about exactly where it’s crashing for you?

10

Its JUCE 4.3.1, but i think the code shouldn’t have changed that much

Bildschirmfoto 2017-05-11 um 13.13.58 Kopie.png2070×1194 266 KB

11

OK, thanks - that did seem like an edge-case that was worth checking, I’ve pushed a fix to develop now.

12

Yeah, somehow I’m encountering this on Windows a year later with JUCE 5.1.2. I take it 5.1.2 was released sometime after May 2017, the last post in this thread.

bad access violation on t* inside of EdgeTable::clearLineSizes();

What is this about? After this occurs the entire UI of my application becomes non responsive visually, but the audio engine is fine. I’m using a rectangle list to paint a waveform rendering (with valid coordinates). Outright puzzled.

Any input would be appreciated. Damn near identical stack trace to the image above.

13

You’re maybe just feeding it with numbers that are big enough to go out of range? If you can share some code that reproduces it, we can take a look, but please only do this if it still happens in the very latest version, as lots has happened since 5.1.2