Search feature not working

[A-ri-eL]

Hi, all! ^-^

System : ~$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm

$ kded5 --version kded5 5.103.0

~$ cherrytree --version CherryTree 1.1.1

The BUG: The search is not working as expected with or without RegExp enabled. A strange thing I noticed is that when I search for "drivedb.h" nothing (No search process even takes place) is returned, but for "drivedb" I get expected result. When doing that in multiple nodes, the search process gets stuck, but the search process goes on and on endlessly even when I interrupt it via the red "x" button. The App closes with no crash dump.

[giuspen]

Hi @A-ri-eL , did this happen also with v1.1.0 or you didn't try that?

[A-ri-eL]

Hi @A-ri-eL , did this happen also with v1.1.0 or you didn't try that?

Yep, the same erroneous behavior: ~$ cherrytree --version CherryTree 1.1.0

But I also checked that on cherrytree_1.0.4-2~Debian12_amd64.deb and there is no such bug, the results are just fine. The only tricky things are that some matches are ignored when they are next to each other (i.e. On the same [long] line) and the offsets for the listed results are not updated when any change is made, misleading further result highlights on the current list dialog box... But if I'm not mistaken that tricky things were fixed on the most recent versions.

Thanks for your return. ^--^

[giuspen]

@A-ri-eL would it be possible to share a test document with data that reproduces the issue and indicating what to search for? Also privately to my email that you can find in help--abou dialog

[A-ri-eL]

@A-ri-eL would it be possible to share a test document with data that reproduces the issue and indicating what to search for? Also privately to my email that you can find in help--abou dialog

I sent a sample to you.

Thanks ^--^!

[giuspen]

Got it thanks @A-ri-eL I will come back with a fix by tomorrow

[giuspen]

I see it. It is happening only with more recent GTK3 library versions. For example if you run the AppImage in your Debian 12, the issue is not happening (The AppImage is built with Debian 11 libraries). Tomorrow anyway I'll try and sort it out.

[giuspen]

@A-ri-eL I think I sorted it out, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+4~Debian12_amd64.deb and report if it now works as expected?

[A-ri-eL]

@A-ri-eL I think I sorted it out, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+4~Debian12_amd64.deb and report if it now works as expected?

That first case is ok now, but I guess there is an inner bug in the RegExp engine 🤔, because when I use a more complex RegExp (i.e. \b(ATA|IDE)\b( disks?| devices?| only)?) I get the same buggy behavior.

[giuspen]

The previous bug was characterised by a GTK / Glib error printed to the terminal. I'm not sure how thorough is the Glib RegExp support and some rules may differ. If you run that from a terminal, can you see any error printed to the terminal with the non working RegExp?

[A-ri-eL]

\b(ATA|IDE)\b( disks?| devices?| only)?

No, unfortunately no error is printed on the terminal.

~$ cherrytree sampl_2s.ctb 
[2024-03-29 16:15:28.361] [   ] [debug] /home/$USER/.config/cherrytree/config.cfg parsed
[2024-03-29 16:15:28.549] [   ] [debug] autosave on 7 min
[2024-03-29 16:15:28.549] [   ] [debug] mod time sentinel is started
[2024-03-29 16:15:28.773] [   ] [debug] Node 1 > -
[2024-03-29 16:15:29.056] [   ] [debug] fs::download_file: start downloading https://raw.githubusercontent.com/giuspen/cherrytree/master/debian/changelog
(...)

Interestingly, that regexp \b(ATA|IDE)\b( disks?| devices?| only)? works as desired on cherrytree_1.0.4-2~Debian12_amd64.deb.

[giuspen]

Sorry @A-ri-eL my misunderstanding, I thought that the regexp was not finding the result but the problem here is different, cherrytree hangs indefinitely trying that regexp on the document that you shared with me, and that is certainly a bug, I will get back with another version for you to try. (also the fact that the same regexp finds something in v1.0.4 and not in v1.1.x is certainly a regression)

[tsvigo]

My search works strangely — I enter the word that needs to be found, click search and the results window does not appear at all. Then I click Search --> Matches and voila — here it is the search results window.

[giuspen]

I'm going to Link here a test version shortly, I will ask you to verify that it works as expected there

[giuspen]

@A-ri-eL could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+6~Debian12_amd64.deb and report if it now works as expected? @tsvigo / other users willing to help in the testing of the search, please find the Linux AppImage and Windows portable version of the so called v1.1.1+6 at https://www.giuspen.net/cherrytree/#testing and report if it works as expected

[A-ri-eL]

@A-ri-eL could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+6~Debian12_amd64.deb and report if it now works as expected? @tsvigo / other users willing to help in the testing of the search, please find the Linux AppImage and Windows portable version of the so called v1.1.1+6 at https://www.giuspen.net/cherrytree/#testing and report if it works as expected

@giuspen now the app is matching all that is specified; but sometimes it is also listing some nonexisting matches on the same line; usually for the last occurrence. I'll send a sample to you.

[giuspen]

@A-ri-eL many thanks for your patience and quality reports on this issue, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+8~Debian12_amd64.deb and report if it now works as expected?

[A-ri-eL]

@A-ri-eL many thanks for your patience and quality reports on this issue, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+8~Debian12_amd64.deb and report if it now works as expected?

@giuspen, now the app is hanging on another RegExp pattern. I'll send a sample to you.

On cherrytree_1.0.4-2~Debian12_amd64.deb it works just fine.

EDIT: I missed to mention that the issue about listing some nonexisting matches is ok now 👍 .

[jonathonmckay]

I am also having (more or less) this problem. Version 1.1.1, on Windows 10. A search (not using Regular Expression) will often just sort of ... stop. The program is still basically responsive after, and like @tsvigo, I can manually open the search results, but they are obviously incomplete.

If I run it from a terminal, I get an error like: [2024-04-01 20:40:06.066] [gtk] [critical] unhandled exception (type Glib::Error) in signal handler: domain: g-regex-error-quark code : 3 what : Error while matching regular expression access: bad offset into UTF string

Most worryingly, once the error has happened (and I think if there is an image embedded in the node), the save button no longer becomes enabled after a change, and I cannot save my work. Perhaps this should be a separate issue report (and for all I know it is), but the user should still have the ability to manually force it to save, whether it thinks it needs it or not.

I have downloaded the portable test version cherrytree_1.1.1.0+8_win64_portable and tried the same search. The application just hung, and I had to force quit it.

Hope this helps.

[giuspen]

@A-ri-eL thanks again for your patience and quality reports on this issue, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+10~Debian12_amd64.deb and report if it now works as expected? @jonathonmckay could you please test https://www.giuspen.net/software/cherrytree_1.1.1.0+10_win64_portable.7z ?

[A-ri-eL]

@A-ri-eL thanks again for your patience and quality reports on this issue, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+10~Debian12_amd64.deb and report if it now works as expected? @jonathonmckay could you please test https://www.giuspen.net/software/cherrytree_1.1.1.0+10_win64_portable.7z ?

@giuspen, the app is not freezing anymore, but the bug about listing some nonexisting matches is back. It can also be verified on the most recent file that I sent to you; i.e. trying [a-z]+\(\), with RegExp enabled, it will list the last match twice, in another almost similar CT file (I'll send to you) some matches are just ignored too.

[jonathonmckay]

@A-ri-eL thanks again for your patience and quality reports on this issue, could you please test https://www.giuspen.net/software/cherrytree_1.1.1-2+10~Debian12_amd64.deb and report if it now works as expected? @jonathonmckay could you please test https://www.giuspen.net/software/cherrytree_1.1.1.0+10_win64_portable.7z ?

Tested with: cherrytree_1.1.1.0+10_win64_portable Search progress bar move a small amount, then just stops. Program hangs. High CPU use, looks like one whole core. No error messages in the terminal it was launched from (just some debug messages).

[giuspen]

@jonathonmckay could you send me some data to reproduce the issue and indicate what to search for? My email is in the help--about dialog

[jonathonmckay]

@giuspen, I very much wish I could. However, I use CherryTree for various notes at work, and due to where I work and the sorts of things I have notes on, I absolutely cannot send you a copy. What I can tell you is the progress bar always seems to stop in the same place*, implying it's the same node it gets stuck on, but I have no way of knowing which node that is (unless there's some debug information I can turn on?)

Interestingly, the word searched for matters: If I search for "access", it gets stuck at about 10%. Search for "excel", gets stuck at about 75%. And "vini", the search finishes.

[jonathonmckay]

I have made an observation: If I start CherryTree from a terminal to see the error message, right before the error during a search will be debug messages like this:

[2024-04-02 19:33:01.963] [ ] [debug] _parse_given_node_content find_iterated_last_name_n_tags_id 536 [2024-04-02 19:33:01.963] [ ] [debug] _parse_given_node_content find_iterated_last_name_n_tags_id 0

If I look at the last number of the last line (sometimes there are several), this seems to point to the node that this causing the problem. In this case "536". I have tested this several times with words I know to break the search (like "access" and "excel" as noted above), and I have noticed that the word I was searching for when the search broke is in the node's Name.

For example, when searching for "access", the number given in the message was 536, which if I find node 536 is called "ACL (Access Control List) Permissions".

I have tested this with a few different words.

[giuspen]

@jonathonmckay could you please test https://www.giuspen.net/software/cherrytree_1.1.1.0+16_win64_portable.7z ?

[jonathonmckay]

I have tested 1.1.1.0+16 on Windows 10. I have tested the words "vini", "excel", and "access" (With "excel" and "access" known to cause the problem for me). All searches worked OK!

[giuspen]

Thanks @jonathonmckay !

[giuspen]

Fixed in v1.1.2

[jonathonmckay]

Just installed 1.1.2 on Windows10. Search seems to be working OK! Thank you for the quick fix!