On Tue, Nov 15, 2016 at 06:45:12PM +0000, Wookey wrote: > On 2016-11-16 04:57 +1030, Ron wrote: > > > > What are you actually building that source with? > > I actually inherited this kernel tree (on a machine that needs a > patched kernel). But I expect it's built with standard debian > kernel-building tools (the chap who did it is not here to ask > currently);
That's why I asked, because I'm skeptical of that - I don't see anything like it in the (many) kernel build trees I have, and the loops you have there do look kind of especially insane ... But if it really is in some corner case of the standard scripts then we have 2 bugs here that ought to be looked at. (Because I'm at least as interested in kernel builds not being buggy as I am with obscure edge cases in this code ;) > and the point is really, not how this was achieved, but how > global deals with it. It dealt with it by saying "you've footgunned yourself", which is how lots of things deal with infinite recursion through the filesystem, they limit it at some arbitrary point (in this case, once you got 50 deep). It didn't crash, or do something terrible, it reported bad input. > > Either way though, if you're actually seriously using this to index > > built kernel trees, then I'd recommend you look at the skip option > > for gtags configuration, to avoid having it uselessly crawl all over > > the build artifacts in the tree in any case, every time you run it > > to update the tags. > > > > And I assume that if you do that, it does index the kernel for you > > just fine? > > Probably, but you were asking for examples/evidence of where there was > actually a problem with global that was fixed in newer upstream > releases. This was one I came across. Bonus points for them actually being real and intractable problems that hinder some real use case though. In this case, the newer code does handle this a bit more elegantly and informatively - but it is still the case that you fed it garbage in a subtree that it never would have indexed anything in anyway. It didn't fail on indexing the _actual_ source there. If you were really using this on that tree as part of doing real work, you'd already *want* to be using the option to skip that part of the tree - and you'd want what's creating the build tree to not be buggy. Fixing either or both of those things makes this problem vanish again. > > We could look at pulling the newer find code in if that's really a > > benefit to someone, > > Given that I found this in the wild, clearly the code for detecting > symlink loops is a benefit, and that could be backported. I'd already had a quick look at that, and it's not a "one liner" but we probably could do something to at least be a bit more informative in this case than just saying "you dived too deep, now you're bent" with a semi-cryptic error message. > Obviously source trees shouldn't be doing that, but it will happen sometimes. Nod. This one is not quite the same sort of showstopper as it would be if it was failing on the actual code - and don't get me wrong, it is good to have it clearly identified and reported, so I'm not handwaving it away - but it's not really a "new upstream or bust" critical problem that clinches that argument one way or another either. If you genuinely care enough about polishing this corner a bit better, we can look at doing something about that if we are going to stick with this version until the Stretch+1 cycle begins. Cheers, Ron
