Control: tags -1 + pending 2016-06-12 13:25 Manuel A. Fernandez Montecelo:
I've been investigating this again and I believe that it's actually a problem with the cwidget library, that has happened since forever.This happens also for example with devscripts and rhythmbox-plugins, which have a long description which makes the main/first subtree (the one with the package name, the second subtree is "Depends") to also "fill" my terminal (expand more than a screenful vertically), like youtube-dl. It doesn't happen with libwiretap5 even if the description is quite long, for example. I think that it has to do with how the cwidget implementation moves the view to jump to where the term being searched appears, and that gets confused when the contents are off the screen or something similar. The backtrace points to line 854 in ./src/cwidget/widgets/tree.cc with the line: while(curr!=start && !matches(*curr)) and with aptitude's menu_tree.cc, line 82. Searching for "yo" in "youtube-dl" screen doesn't produce the desired effect (I presume), of searching e.g. inside the Description field. When the screen starts at line "zero" [1], with incsearch enabled, "y" jumps to the line below [2], after "yo" jumps to the last line (below [3]), after "you" the same (and at this point it didn't hang yet, one can delete with backspace etc). With "youk" enters the infinite loop. If one presses "yok", or "you<BACKSPACE>k", it also triggers the infinite loop. It will need quite some debugging, and probably a new cwidget release to get this fixed.
Marking as pending. I append here the commit message: ======== Avoid endless loop when searching in "package info screen" (Closes: #802648) Long explanation because it took a long while to dig all this info and understand the problem, and if this is recorded it can help to explain many of the problems and circumstances that concur. When the widget in focus is large (mostly a package with a very long description that is larger than the screen; and the view is completely filled by this description and doesn't there are no other tree nodes in focus --like the main package name at the top, or Depends or others in the bottom--), then a search which doesn't lead to other elements of the tree enters in an endless loop. As the original report explains, this is triggered for example with the package "youtube-dl" which contains a long description with many of the websites that it supports, in the "package info screen", and when the scroll is moved 1 line down, so the only thing visible (even in a moderately large screen) is part of this description. When typing "/" to start search and then "you", the page starts to jump for the incremental search (matching for example the first version of the package that appears as node under "Versions of youtube-dl"), but then if a further "k" is typed, as the original reported did (presumably to verify if the program supported sites named "youku" and "youku:show" that appear in the description), it doesn't match any other node in the tree and it entered an endless loop. The code does not support search within this kind of special node, which it could do; but failing that what it should happen instead is that, in the absence of matches, it goes back to the original view. The reason why this happens is not fully understood, the code is messy and difficult to grok. It seems that the loops expect to stop when either there's a match or when "curr == start" (so it went through all elems and didn't find a match), but this never ends up happening, either because the iteration (which involves C++ operators and iterators traversing either hierarchical or flat version of the tree) doesn't really go through all of the nodes or because they are not considered because they are "out of view". The node where the description appears is not a regular node of the tree, it is one bolted with many package related fields like Description and Homepage, but different from the rest of the nodes of the tree which are only package names, versions, dependencies and so on. The code was clearly designed with these simpler nodes in mind, and the node with the Description is clearly an abuse of the concept. So basically the best solution found to avoid the endless loop was to just stop when the loop goes through "end" for second time, if there were no matches. It's not optimal, but acceptable in terms of performance, specially having into account that it's not an operation performed in tight loops and the difference is not noticeable with other searches. A proper solution would mean to really redesign both cwidget and packages using it like aptitude so the info page is not designed as a tree and then riding one of the nodes with all sorts of extra information which is not searchable. Cheers. -- Manuel A. Fernandez Montecelo <[email protected]>
