Stackoverflow in returnLabeLToOriginImmediately

[nightfall708]

Hi,

I'm investigating now a stack overflow case where returnLabeLToOriginImmediately keeps calling it self.

- (void)returnLabelToOriginImmediately {
    NSArray *labels = [self allSubLabels];
    CGFloat offset = 0.0f;
    for (UILabel *sl in labels) {
        [sl.layer removeAllAnimations];
        sl.frame = CGRectOffset(self.homeLabelFrame, offset, 0.0f);
        offset += (self.marqueeType == MLContinuousReverse ? -1 : 1) * (self.homeLabelFrame.size.width + self.fadeLength + self.continuousMarqueeExtraBuffer);
    }

    if (self.subLabel.frame.origin.x == self.homeLabelFrame.origin.x) {
        self.awayFromHome = NO;
    } else {
        [self returnLabelToOriginImmediately];
    }
}

So as you can see the IF statement the end is false.

This happens on iOS 7.0 Beta 6. I'm setting the label after the view has appeared.

[cbpowell]

Are you using the latest version of MarqueeLabel? This is similar to issue #31, which I thought was solved but I have not strenuously tested on, ahem, unreleased iOS versions.

[nightfall708]

I'm using the latest version. I read #31, I think the key issue is something that has to do with unicode characters, as the string that's causing my crash contains "á" and "õ" and on #31 it's 'Sternwartestraße, Betrieb...'.

more things:

• If I change the content of the string it doesn't crash anymore.
• If I change the font of the string it doesn't crash anymore.
• I tried the string and with/without the font on the demo app and it won't crash.
• the crash occurs on setText, before the label was added to the view.

[cbpowell]

Hmm interesting, good data points. I'd noticed the unicode characters when working on #31 as well, but had hoped making sure the rects were integral would help. Sounds like this might be getting into the black magic of font spacing/sizing, so one possible option might just be to eliminate the recursive call.

The root cause of the recursion is the fact that self.subLabel.frame.origin.x == self.homeLabelFrame.origin.x is equating to NO, and on #31 it was due to a non-integral x position of the actual sublabel, not the homeLabelFrame. Might need to do some more digging into why that's occuring with unicode strings.

[nightfall708]

Thanks, I've lost you there on the second paragraph, on what that condition really means.
What are the consequences of eliminating the recursive call?

[cbpowell]

It'll probably still be fine if you remove the recursion, so if you need to get something non-crashy out you could probably remove it.

[nightfall708]

Thanks I'll do that.

[gammapoint]

We too are seeing this issue reported by our European users, so removed the recursion, hopefully this works.

It worked. No more crashes reported by European users.

[afeick]

We ran into the same issue without unicode characters. The self.subLabel.frame.origin.x was off by hundredths or less, and we were able to work around it by converting the value to an integer and then comparing it.

Also, this only happened on an iPad running iOS7 when the app is built using XCode 5. (Did not happen on any iPhones, any iOS6 or when the app was built using Xcode 4.6.)

[cbpowell]

So I noticed that I wasn't initializing the fadeLength CGFloat variable to zero when a MarqueeLabel is init'd, which could have had something to do with this problem since fadeLength is used for the x position when creating self.homeLabelFrame. I've corrected that in the recent update, and added in CGRectIntegral calls in other places to help prevent fractional frames/positions.

I've always had trouble replicating this (no clue why!), but if this fixes it for you guys that have had trouble please report back.

[gammapoint]

Does the update fixes the issue seen in iPad or the unicode char problem?

[cbpowell]

Well only the Unicode characters I'd think, but I can't say for sure. I actually don't have an iOS7 iPad for testing right now.

On Mon, Nov 11, 2013 at 12:56 AM, gammapoint notifications@github.com
wrote:

Does the update fixes the issue seen in iPad or the unicode char problem?

Reply to this email directly or view it on GitHub:
#35 (comment)

[cbpowell]

I'm also going to remove the recursion from this call. At worst the result would be some screwy animation, which is still better than a hard crash due to a stack overflow.

[nthenoz]

Hi,
I encountered this bug and found a working workaround (at least it seems so).
In my case, in the returnLabelToOriginImmediately method, the CGRectOffset(self.homeLabelFrame, offset, 0.0f) call added a 0.0002 px to the frame origin. To resolve this, I added CGRectIntegral before CGRectOffset(self.homeLabelFrame, offset, 0.0f) and all my values are now rounded

[cbpowell]

Thanks @nthenoz, I put a few more CGIntegralRect checks into the v1.4.1 release to maybe prevent these issues. Doesn't seem like it's happening to people all that often anymore, so maybe it's getting closer to being fixed...

[cbpowell]

I believe this should be completely fixed with the release of v2.0.0. The check is no longer performed, and the returnLabelToOriginImmediately method works differently (by removing the animation).