Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

problems with anchored searches #46

Open
dsheyp opened this issue Feb 8, 2016 · 8 comments
Open

problems with anchored searches #46

dsheyp opened this issue Feb 8, 2016 · 8 comments
Labels

Comments

@dsheyp
Copy link
Contributor

dsheyp commented Feb 8, 2016

I'm doing an anchored search (see manual for anchored searches ) like the following:

filename:"^My_File_Name" ext:pdf Hello dir:"home/abel/documents/my folder"

It will result in crashing the docker container where my recoll and recoll-webui runs. While the following works:

filename:"My_File_Name" ext:pdf Hello dir:"home/abel/documents/my folder"

The only difference is the ^ in front of the file name.

I'm not sure whether it is webui or recoll itself that produces the crash.

@koniu
Copy link
Owner

koniu commented Feb 8, 2016

Hello. Not been able to reproduce - we will need a log/traceback from recoll-webui run.

Don't know much about Docker but I'm told you can get logs with docker logs -f <container>. Assuming that Docker redirects stdout/stderr to the logs, you can run that before you execute your deadly query and you should see a traceback there.

@koniu koniu self-assigned this Feb 8, 2016
@dsheyp
Copy link
Contributor Author

dsheyp commented Feb 8, 2016

Hello. Thanks for answering so fast.

I had a look into the recoll log. It says:

:4:../common/rclconfig.cpp:454:RclConfig::initThrConf: autoconf requested
:4:../utils/execmd.cpp:330:ExecCmd::startExec: (0|1) sh {-c} {egrep ^processor /proc/cpuinfo | wc -l}
:4:../utils/execmd.cpp:683:ExecCmd::wait: got status 0x0
:4:../common/rclconfig.cpp:506:RclConfig::initThrConf: chosen config (ql,nt): (2, 4) (2, 2) (2, 1)
:4:pyrecoll.cpp:1552:Db_init
:4:../rcldb/rcldb.cpp:756:Db::open: m_isopen 0 m_iswritable 0 mode 0
:4:pyrecoll.cpp:1611:Db_query
:4:pyrecoll.cpp:828:Query_new
:4:pyrecoll.cpp:850:Query_init
:4:../rcldb/rclquery.cpp:176:Query::setQuery:
:4:../rcldb/searchdata.cpp:183:SearchData::toNativeQuery: stemlang [english german german2]
:4:../rcldb/searchdata.cpp:1091:SearchDataClauseDist::toNativeQuery
:4:../rcldb/searchdata.cpp:875:StringToXapianQ:pUS:: qstr ["^My_File_Name"] fld [filename] mods 0x0 slack 0 near 0

To me it seems the request gets through to recoll and I think the problem is on the recoll side. I guess this is something that I'll have to address with the recoll developper...

@ghost
Copy link

ghost commented Feb 8, 2016

Done. :) what recoll version?
I won't be able to do much about it this week anyway, but I'll take a look when I get back

@koniu koniu removed their assignment Feb 8, 2016
@koniu koniu added the upstream label Feb 8, 2016
@dsheyp
Copy link
Contributor Author

dsheyp commented Feb 9, 2016

That was fast :-)
I think it was version 1.20.5. But I updated now to 1.21.5, and the crashes are gone! But still it doesn't work exactly as I would expect. If I do the following search:

filename:"^My_File_Name" ext:pdf Hello dir:"home/abel/documents/my folder"

with or without the leading ^ it depends on the length of "My_File_Name", whether it finds the correct file or not. I have a file where "My_File_Name" consists of 41 characters, like this:

Andrea_Donacombar_Selenitectos_Feralenes.pdf

and the above search will only work, when I remove the _Feralenes.pdf part of the filename. Also the following searches will not work

filename:"Andrea_Donacombar_Selenitectos_Feralenes" ext:pdf Hello dir:"home/abel/documents/my folder"
filename:"Feralenes.pdf$" ext:pdf Hello dir:"home/abel/documents/my folder"
filename:".pdf$" ext:pdf Hello dir:"home/abel/documents/my folder"

while the following will work

filename:"pdf$" ext:pdf Hello dir:"home/abel/documents/my folder"
filename:"Andrea_Donacombar_Selenitectos" ext:pdf Hello dir:"home/abel/documents/my folder"
filename:"Selenitectos_Feralenes.pdf" ext:pdf Hello dir:"home/abel/documents/my folder"

I think the dot . of the file extension might be a problem in anchored searches?
May be there is some sort of limitations of filename length?
Or may be there is just something with my installation of recoll and webui. I use it in a debian docker container on a synology nas (see here for the specs of the container).

@ghost
Copy link

ghost commented Feb 9, 2016

Recoll is probably doing something wrong. Will take a better look next week.

@koniu koniu changed the title Crashes with anchored searches problems with anchored searches Feb 9, 2016
@koniu
Copy link
Owner

koniu commented Feb 9, 2016

@dsheyp some good digging there!

I haven't played as far and deep but can confirm similar problematic behaviour on 1.17.3. This is thru both webui and the QT client. What's worse, I accidentally discovered that they both segfault when you enter a $ as a search term.

@ghost
Copy link

ghost commented Feb 13, 2016

I'll only comment on the latest versions (1.21 and trunk), 1.20 and 1.17 will not be updated anyway.

What happens is that you are hitting the maximum term length which is set at 40 characters (the whole name without the extension is 41 characters). The trunk code will warn about this, I'm not sure about 1.21, and the warning might not make it through the webui anyway.

One way to go around this is to not enter the _ characters (and/or . for the extension). If you do enter them, recoll tries for a span (compound word) match, and hits the term length limit. If you enter the same query without the glue chars, things work as far as I can see.

This is unfortunate, but I have no idea how to fix it in a reasonably simple way. Using spans has some good aspects (avoiding slow phrase searches for things like email addresses), and some bad, one of which you found out.

Maybe I could revert to a split and phrase search if the span is too long, this needs further study. I'm putting it on the todo list. I guess that this is a recoll issue in any case, and that this can be closed as a webui issue.

@ghost
Copy link

ghost commented Feb 13, 2016

And thanks for taking the time to study the issue !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants