KERN_INVALID_ADDRESS in replaceRectRGB

#1

Hi Jules,

Any idea what this might mean? Looks like something dodgy is going on. We’ve had this report from one of our Mac users, hence raising it in this thread… :slight_smile:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x807abb96

Thread 0 Crashed:
0   com.x.y           0x00096826 juce::replaceRectRGB(unsigned char*, int, int, int, juce::Colour const&) + 162
1   com.x.y           0x00096a36 juce::LowLevelGraphicsSoftwareRenderer::clippedFillRectWithColour(juce::Rectangle const&, int, int, int, int, juce::Colour const&, bool) + 200
2   com.x.y           0x00096d5a juce::LowLevelGraphicsSoftwareRenderer::fillRectWithColour(int, int, int, int, juce::Colour const&, bool) + 114
3   com.x.y           0x0004eca1 juce::Graphics::fillAll(juce::Colour const&) const + 103
4   com.x.y           0x000793a1 juce::ResizableWindow::paint(juce::Graphics&) + 29
5   com.x.y           0x0007740a juce::DocumentWindow::paint(juce::Graphics&) + 26
6   com.x.y           0x00030bfb juce::Component::paintEntireComponent(juce::Graphics&) + 639
7   com.x.y           0x00084b3c juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 50
8   com.x.y           0x00101ce3 juce::HIViewComponentPeer::RepaintManager::paint(CGContext*, int, int, int, int) + 835
9   com.x.y           0x001022bb juce::HIViewComponentPeer::hiViewDraw(OpaqueEventRef*) + 791 
10  com.ix.y          0x001024ac juce::HIViewComponentPeer::hiViewEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 420
11  com.apple.HIToolbox                0x92dee4d7 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093

TIA!

Pete

#2

Never seen that before. But it’s obviously trying to draw to an out-of-range area of the graphics context.

That shouldn’t ever be possible, but it rings a bell with something that came up recently - it used to be possible to do a setBounds inside a paint() callback, and that could (well… maybe) mess things up sufficiently to get this to happen. I added an assertion to catch that a couple of days ago.

Can’t think of anything else other than memory corruption that could make it go so wrong!

#3

Hi Jules!

It seems pretty likely that the problem was somehow provoked by having a 2nd monitor in use. The problem has currently gone away for the user in question (!): I must admit that I’ve never seen a second monitor cause a problem, so this is pretty weird!

Anyways, don’t panic: but hopefully the theory that a 2nd monitor is behind the problem might make you think what was beind this at some point!

Pete

#4

Can’t really think how a second monitor would affect it… It’s the same Graphics object that’s doing the drawing, regardless of where it’s going to end up. Very odd…

#5

Hi Jules,

We’ve had another user report the same basic problem:

Any more ideas on this?!

It was on Mac OS 10.5.1, 4GB MacBook, intel.

:frowning:

I’ll let you know what else I find out…

Pete

#6

Hi Jules,

Having been poring-over the implementation of replaceRectRGB in juce_LowLevelGraphicsSoftwareRenderer.cpp, I have a working theory that the app might have passed-in a value of w or h equal to zero for a paint operation…?

Your code pre-decrements w and h values before comparison to zero, so I suspect that this is what triggers the exception. I’ll keep checking!

I don’t suppose this is something that Juce could actively guard against in some future build?

Pete

#7

my pre-decrementing should work fine, I’d suspect this is more likely to be that it’s trying to write to an image that’s toasted, or trying to write beyond the edge of an image. Can’t think why though…

#8