Ticket #3819 (closed defect: fixed)
[mcview] Search doesn't grow file as much as needed
| Reported by: | egmont | Owned by: | andrew_b |
|---|---|---|---|
| Priority: | major | Milestone: | 4.8.20 |
| Component: | mcview | Version: | master |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Branch state: | merged | Votes for changeset: | committed-master |
Description
(Somewhat similar to #3817)
Searching only loads one more additional fragment of the growing file, rather than as much as needed. Hence it often fails to find a match.
Steps to reproduce:
- Find a big enough file whose contents are "parsed" on F3. Maybe a library, or a compressed achive. For example, libboost_thread.so.1.62.0.
- Open it for viewing by pressing F3.
- Scroll to the end of the file, and copy a string that appears there, but not earlier in the file. E.g. a pointer value in the aforementioned library.
- Close the file and open again.
- Search for this string.
Notice that "Search string not found" is reported, and the offset "8192+" grows to "16384+" in the top bar.
Press 'n' or F7 Enter over and over again, each time the offset grows by another 8192 until eventually the match is located.
Attachments
Change History
comment:3 Changed 8 years ago by andrew_b
- Status changed from new to accepted
- Owner set to andrew_b
- Branch state changed from no branch to on review
- Milestone changed from Future Releases to 4.8.20
Branch: 3819_mcview_search_grow
changeset:c4c81468a7168214608c2a3867afbab9498cc7d9
comment:4 Changed 8 years ago by egmont
Seems to work correctly, thanks! (I haven't looked at the code, only tested the behavior.)
Not sure if I can piggyback this bugreport with yet another issue or should open a new one:
mcview -> F5 -> Goto offset suffers from the same problem.
(Goto line number works as expected. Goto percent is an interesting question, currently it jumps to the percent of the already loaded amount, which is not that user-friendly, however, the proper solution would require to load the entire stream - are we okay with that?)
comment:5 Changed 7 years ago by andrew_b
- Votes for changeset set to andrew_b
- Branch state changed from on review to approved
comment:6 Changed 7 years ago by andrew_b
- Status changed from accepted to testing
- Votes for changeset changed from andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [2e834a72f14aae07c2b0916590605c90b75a45cd].
This was broken in commit dc03e9e28d9c58df9c37e6911e54944fd5a5bdca.
Since that version, though, the behavior is not exactly as described above. The search attempt loads the entire file, just fails to find the match if it's near the end of the file (perhaps in the last, partial 8kB block -- just a guess).
Then later it was commit 7f8ab40a44720265d1d33577b3404bf9ca8be9fa that changed to only load one single 8kB block per search attempt.
Andrew, this seems to be your area, could you please look at this? Thanks!