search

Andersbakken / rtags

A client/server indexer for c/c++/objc[++] with integration for Emacs based on clang.
http://www.rtags.net
GNU General Public License v3.0
1.83k stars 252 forks source link

rdm server gets stuck in ScanThread when running rc -J #1023

Closed Kaali closed 7 years ago

Kaali commented 7 years ago

Please mark appropriate

Problem description

rdm server gets stuck in ScanThread when running rc -J. It happens because my project has a lot of files, and many of them are on a network drive. When I run rc -J on the project, it reports 'Compilation database loading...' and quits. After that I cannot access rdm in any way, which means that all tools using rtags gets stuck while the scan is in progress.

Expected behavior

rdm daemon should either respond that it's processing a project and cannot answer queries, or the processing should be done asynchronously if possible.

Actual behavior

rdm gets completely stuck. With a callstack:

... cut visitors ...
#15 0x0000559e62e3aa2a in Path::visit(std::function<Path::VisitResult (Path const&)> const&) const (this=this@entry=0x7ffe8efc6e30, 
    callback=...) at /home/xxx/code/rtags/src/rct/rct/Path.cpp:611
#16 0x0000559e62f2156d in ScanThread::paths (path=..., filters=...) at /home/xxx/code/rtags/src/ScanThread.cpp:45
#17 0x0000559e62ea760f in FileManager::load (this=0x559e643543a0, mode=<optimized out>, mode@entry=FileManager::Synchronous)
    at /home/xxx/code/rtags/src/FileManager.cpp:40
#18 0x0000559e62dafdf8 in Server::setCurrentProject (this=this@entry=0x559e63ab83b0, 
    project=std::shared_ptr (count 3, weak 3) 0x559e64837150) at /home/xxx/code/rtags/src/Server.cpp:1446
#19 0x0000559e62dbaccb in Server::handleIndexMessage (this=this@entry=0x559e63ab83b0, message=
    std::shared_ptr (count 3, weak 0) 0x559e63ab7d50, conn=std::shared_ptr (count 3, weak 2) 0x559e63be1630)
    at /home/xxx/code/rtags/src/Server.cpp:633
#20 0x0000559e62dc4f36 in Server::onNewMessage (this=0x559e63ab83b0, message=..., 
    connection=std::shared_ptr (count 3, weak 2) 0x559e63be1630) at /home/xxx/code/rtags/src/Server.cpp:369
#21 0x0000559e62e22f77 in std::function<void (std::shared_ptr<Message>, std::shared_ptr<Connection>)>::operator()(std::shared_ptr<Message>, std::shared_ptr<Connection>) const (__args#1=std::shared_ptr (expired, weak 0) 0x7ffe8efc74d0, 
    __args#0=std::shared_ptr (count 1672574352, weak 21917) 0x7ffe8efc74b0, this=<optimized out>) at /usr/include/c++/6/functional:2127
#22 Signal<std::function<void (std::shared_ptr<Message>, std::shared_ptr<Connection>)> >::operator()<std::shared_ptr<Message>&, std::shared_ptr<Connection>&>(std::shared_ptr<Message>&, std::shared_ptr<Connection>&) (this=0x559e63be16b0)
    at /home/xxx/code/rtags/src/rct/rct/SignalSlot.h:70
#23 Connection::onDataAvailable(std::shared_ptr<SocketClient> const&, Buffer&&) (this=0x559e63be1630, client=..., buf=<optimized out>)
    at /home/xxx/code/rtags/src/rct/rct/Connection.cpp:154
#24 0x0000559e62e45509 in std::function<void (std::shared_ptr<SocketClient> const&, Buffer&&)>::operator()(std::shared_ptr<SocketClient> const&, Buffer&&) const (__args#1=<optimized out>, __args#0=..., this=0x559e63be36b8) at /usr/include/c++/6/functional:2127
#25 Signal<std::function<void (std::shared_ptr<SocketClient> const&, Buffer&&)> >::operator()<std::shared_ptr<SocketClient>&, Buffer>(std::shared_ptr<SocketClient>&, Buffer&&) (this=0x559e63ab7aa0) at /home/xxx/code/rtags/src/rct/rct/SignalSlot.h:70
#26 SocketClient::socketCallback (this=0x559e63ab7a50, f=<optimized out>, mode=1)
    at /home/xxx/code/rtags/src/rct/rct/SocketClient.cpp:685
#27 0x0000559e62e2bc34 in std::function<void (int, unsigned int)>::operator()(int, unsigned int) const (__args#1=<optimized out>, 
    __args#0=<optimized out>, this=0x7ffe8efcbd70) at /usr/include/c++/6/functional:2127
#28 EventLoop::fireSocket (this=this@entry=0x559e63ab81b0, fd=8, mode=1) at /home/xxx/code/rtags/src/rct/rct/EventLoop.cpp:710
#29 0x0000559e62e2ca65 in EventLoop::processSocketEvents (this=this@entry=0x559e63ab81b0, events=events@entry=0x7ffe8efcbfb0, 
    eventCount=<optimized out>) at /home/xxx/code/rtags/src/rct/rct/EventLoop.cpp:851
#30 0x0000559e62e2e531 in EventLoop::exec (this=0x559e63ab81b0, timeoutTime=<optimized out>)
    at /home/xxx/code/rtags/src/rct/rct/EventLoop.cpp:964
#31 0x0000559e62d8c3c7 in main (argc=<optimized out>, argv=<optimized out>) at /home/xxx/code/rtags/src/rdm.cpp:846

Environment

Feature request

Server itself should never stop responding so that external tools such as editors won't get stuck even if rtags cannot process requests.

Andersbakken commented 7 years ago

I tend to agree. There are many of the functions in rtags.el that are synchronous in nature however so it will always be possible for rtags to lock up your editor. This particular one doesn't seem like it needs to be though. I've changed that. You may also want to disable the scan thread for those directories by putting a file called .rtags-ignore in the root of the network drive.

Let me know if this patch doesn't fix it.

Thanks for the report.