avoid hang in stringValue #2243
Conversation
splitObjects tries three things: check if count is 1, check for object components, get children. We already know the count is not one, and getting children (if it doesn't cause a loop) just splits the string on \n, which we would only reverse here. So go straight for the object components. fixes #2242
stringValue is a bit heavy handed. We know the text is present since we test for it, and we know that's what stringValue will end up returning (after doing many tests).
|
I like the 2nd commit, even though it is probably still a bit hacky. Since what you said about us storing identifiers for text objects is no longer the case, can it not just be removed in its entirety? It seems a bit 'black magic' to me! |
I found the reason for that code. See #1858. Sounds like the identifiers were getting stored as text, but they referred to more complicated objects. Makes more sense than text objects with identifiers surviving in someone’s indexes all this time. I’m still not sure if it’s safe to remove, though. I can look deeper tomorrow with fresh eyes. |
| // get the string value for each object in the collection | ||
| stringValue = [[[self splitObjects] arrayByPerformingSelector:@selector(stringValue)] componentsJoinedByString:@"\n"]; | ||
| stringValue = [[[obj objectForCache:kQSObjectComponents] arrayByPerformingSelector:@selector(stringValue)] componentsJoinedByString:@"\n"]; |
There was a problem hiding this comment.
so will there ever be a case that the kQSObjectComponents won't have been set yet when you get here?
There was a problem hiding this comment.
I couldn’t get it into that state, but it must be possible, otherwise children would have never been called when we were using splitObjects as described in your report of the issue.
If it’s not set, it moves to the next thing. No big deal, since this entire section didn’t exist a year ago.
There was a problem hiding this comment.
True, what you added is an improvement, and if it's not there it'd be "how it always was"
I'm going to merge but then add a comment RE this isn't ideal - incase it catches us out one day
(and why we didn't use `[obj splitObjects]`. More info in the commit message of c43577d
|
OK I pushed a small change to add a comment to your change. I'm happy with this as is (even if it is slightly hacky). Now the question is: should the If this is true, then either this usage of |
|
Oh, wait... the reason it's failing is because
Now we have the eternal dilemma of tests failing because they don't represent the real world... because the real world is way too complicated! |
In unit tests, calling QSGetApplicationSupportFolder() might return nil and cause a crash - because QSApplicationSupportPath was never set. These changes make sure it's always set (and in fact stop QSApplicationSupportPath from being extern
|
OK, let's try and get this merged so we're not sidetracked and discussing something else for ever! I've commented out the problematic unit tests, to be revised at a later date |
Yes, thank you! It’s supposed to be a stupid one-line change. |
I could never induce
splitObjectsto callchildren, even following the steps in #2242, but the potential for an infinite loop was undeniable. Good catch, @pjrobertson!This should prevent such a loop. The second commit may or may not help as well, but at worst, it makes things more efficient.