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 253 forks source link

Rtags frequently locks emacs #996

Open clearmisp opened 7 years ago

clearmisp commented 7 years ago

Please mark appropriate

Problem description

Rtags frequently causes Emacs to freeze, the only way to wake Emacs up again is by doing C-g multiple times. I have Emacs configured to show a backtrace in a Backtrace buffer whenever I do C-g. It clearly shows that Rtags is busy calling rc:

Debugger entered--Lisp error: (quit)
  call-process-region(1 140 "/home/micke/.emacs.d/elpa/rtags-20170527.450//rtags-2.10/bin/rc" "/tmp/emacseW5maW" nil nil "--silent-query" "--silent" "-z" "--verify-version=122" "--set-buffers" "-")
  apply(call-process-region 1 140 "/home/micke/.emacs.d/elpa/rtags-20170527.450//rtags-2.10/bin/rc" nil nil nil ("--silent-query" "--silent" "-z" "--verify-version=122" "--set-buffers" "-"))
  rtags-call-process-region(1 140 "/home/micke/.emacs.d/elpa/rtags-20170527.450//rtags-2.10/bin/rc" nil nil nil "--silent-query" "--silent" "-z" "--verify-version=122" "--set-buffers" "-")
  apply(rtags-call-process-region 1 140 "/home/micke/.emacs.d/elpa/rtags-20170527.450//rtags-2.10/bin/rc" nil nil nil ("--silent-query" "--silent" "-z" "--verify-version=122" "--set-buffers" "-"))
  rtags-call-rc(:noerror t :silent-query t :silent t :path t :unsaved #<buffer  *temp*> "--set-buffers" "-")
  rtags-set-buffers((#<buffer AutomatedOutgoingCall.cpp> #<buffer *compilation*> #<buffer c_call.cpp> #<buffer  *Minibuf-1*> #<buffer *ansi-term*> #<buffer c_call.h> #<buffer *grep*> #<buffer *magit: LCC> #<buffer *magit-diff: LCC> #<buffer *scratch*> #<buffer  *Minibuf-0*> #<buffer *Messages*> #<buffer  *code-conversion-work*> #<buffer  *Echo Area 0*> #<buffer  *Echo Area 1*> #<buffer *helm recentf*> #<buffer *rdm*> #<buffer  *Irony*> #<buffer *RTags Log*> #<buffer *helm grep*> #<buffer  *helm candidates:Emacs Commands*> #<buffer *helm M-x*> #<buffer  *helm candidates:Occur*> #<buffer *helm occur*> #<buffer *RTags*> #<buffer *helm buffers*> #<buffer *Backtrace*> #<buffer  *helm candidates:kill-buffer*> #<buffer *helm-mode-kill-buffer*> #<buffer *helm find files*> #<buffer *helm*>))
  rtags-update-buffer-list()
  apply(rtags-update-buffer-list nil)
  timer-event-handler([t 0 1 0 nil rtags-update-buffer-list nil idle 0])

This happens quit a lot.

Expected behavior

Emacs shouldn't freeze when rtags is calling rc, if rc is busy or unresponsive the call should timeout.

Actual behavior

Emacs freezes and becomes unresponsive and only wakes up after multiple C-g.

Environment

Andersbakken commented 7 years ago

Is it usually the rtags-set-buffers causing this?

It does seem like we can make this quite a bit more efficient by only telling rtags about buffers that have been removed or added rather than updating the whole list every time. I'll try to do something about it.

Andersbakken commented 7 years ago

I have changed it up a little. Can you see if this helps?

Incidentally, do you often have lots of buffers open in Emacs?

FinnG commented 7 years ago

I also experience this issue, exactly as described by @clearmisp. I would say that it does tend to occur when I have lots of buffers open.

Running top on my system whilst things are hanging shows rdm using 100% cpu. I've been meaning to attach a debugger to it when I get this problem to see what's going on but I've not had chance to get round to this yet.

I've not tried the latest commit on this issue yet, but will aim to get round to it.

Andersbakken commented 7 years ago

I'd be glad to hear if it helps the issue at all.

On Mon, Jul 17, 2017 at 6:30 AM, Finn Grimwood notifications@github.com wrote:

I also experience this issue, exactly as described by @clearmisp https://github.com/clearmisp. I would say that it does tend to occur when I have lots of buffers open.

Running top on my system whilst things are hanging shows rdm using 100% cpu. I've been meaning to attach a debugger to it when I get this problem to see what's going on but I've not had chance to get round to this yet.

I've not tried the latest commit on this issue yet, but will aim to get round to it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/996#issuecomment-315755806, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSr-aGIItbTHrJ_SdAcjWemfi2pSOks5sO2HlgaJpZM4OH9IK .

FinnG commented 7 years ago

I don't believe this is fixed in the latest release (2.11). I seem to hit this issue more regularly when I have more than one Emacs open but I'm not 100% sure about this yet. I can reproduce the issue doing more or less anything I usually do with rtags, probably 95% of which are the following functions: rtags-find-symbol-at-point, rtags-find-references and rtags-find-symbol.

I was able to attach a debugger to rdm when it's in it's 'wedged' state and capture a backtrace. Sampling several times reveals that we've always got Project::dependsOn near the top of the stack. I'm happy to look at this a bit more if you want to know anything more specific.

#0  0x00007f311e6b119c in __GI___libc_malloc (bytes=24) at malloc.c:2924
#1  0x00007f311f5e2e78 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00000000005af963 in _M_init_functor (__f=<optimized out>, __functor=...) at /usr/include/c++/5/functional:1787
#3  _M_init_functor (__f=<optimized out>, __functor=...) at /usr/include/c++/5/functional:1758
#4  function<Project::dependsOn(uint32_t, uint32_t) const::<lambda(DependencyNode*)>, void, void> (__f=..., this=0x7ffc8ad02620) at /usr/include/c++/5/functional:2254
#5  Project::dependsOn (this=0x27bedf0, source=2210, header=header@entry=777) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Project.cpp:1021
#6  0x0000000000563eab in CompletionThread::isCached (this=<optimized out>, fileId=fileId@entry=777, project=std::shared_ptr (count 2, weak 3) 0x27bedf0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/CompletionThread.cpp:586
#7  0x000000000047fcfd in Server::prepareCompletion (this=this@entry=0x24b14d0, query=std::shared_ptr (count 3, weak 0) 0x250f000, fileId=fileId@entry=777, project=std::shared_ptr (count 2, weak 3) 0x27bedf0)
    at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:2416
#8  0x000000000048cb2f in Server::diagnose (this=this@entry=0x24b14d0, query=std::shared_ptr (count 3, weak 0) 0x250f000, conn=std::shared_ptr (count 3, weak 2) 0x2a330e0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:979
#9  0x0000000000495b76 in Server::handleQueryMessage (this=this@entry=0x24b14d0, message=std::shared_ptr (count 3, weak 0) 0x250f000, conn=std::shared_ptr (count 3, weak 2) 0x2a330e0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:712
#10 0x0000000000495ea6 in Server::onNewMessage (this=0x24b14d0, message=..., connection=std::shared_ptr (count 3, weak 2) 0x2a330e0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:372
#11 0x00000000004f303b in operator() (__args#1=std::shared_ptr (expired, weak 0) 0x7ffc8ad02cc0, __args#0=std::shared_ptr (count 45870384, weak -1) 0x7ffc8ad02ca0, this=<optimized out>) at /usr/include/c++/5/functional:2267
#12 operator()<std::shared_ptr<Message>&, std::shared_ptr<Connection>&> (this=0x2a33160) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/SignalSlot.h:70
#13 Connection::onDataAvailable(std::shared_ptr<SocketClient> const&, Buffer&&) (this=0x2a330e0, client=..., buf=<optimized out>) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/Connection.cpp:154
#14 0x0000000000514e3e in operator() (__args#1=<optimized out>, __args#0=..., this=0x2571998) at /usr/include/c++/5/functional:2267
#15 operator()<std::shared_ptr<SocketClient>&, Buffer> (this=0x2530ca0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/SignalSlot.h:70
#16 SocketClient::socketCallback (this=0x2530c50, f=<optimized out>, mode=1) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/SocketClient.cpp:685
#17 0x00000000004fbcb0 in operator() (__args#1=1, __args#0=15, this=0x7ffc8ad07560) at /usr/include/c++/5/functional:2267
#18 EventLoop::fireSocket (this=this@entry=0x24b1250, fd=15, mode=1) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/EventLoop.cpp:710
#19 0x00000000004fcaa9 in EventLoop::processSocketEvents (this=this@entry=0x24b1250, events=events@entry=0x7ffc8ad077b0, eventCount=<optimized out>) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/EventLoop.cpp:851
#20 0x00000000004fe77a in EventLoop::exec (this=0x24b1250, timeoutTime=timeoutTime@entry=-1) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/EventLoop.cpp:964
#21 0x000000000045cf6c in main (argc=<optimized out>, argv=<optimized out>) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rdm.cpp:846
Andersbakken commented 7 years ago

Disabling completions would likely help somewhat. RTags can be chatty at times and every synchronous call will have a stack like this and will hang emacs until it completes.

Certain things can probably be optimized and certain calls from elisp to rdm can possibly be eliminated but the short of it is that RTags is kinda greedy on resources.

If you don't actively use completions I would definitely try to disable them and see if it helps though.

I would also recommend compiling rdm in release.

Anders

On Mon, Jul 31, 2017 at 6:32 AM, Finn Grimwood notifications@github.com wrote:

I don't believe this is fixed in the latest release (2.11). I seem to hit this issue more regularly when I have more than one Emacs open but I'm not 100% sure about this yet. I can reproduce the issue doing more or less anything I usually do with rtags, probably 95% of which are the following functions: rtags-find-symbol-at-point, rtags-find-references and rtags-find-symbol.

I was able to attach a debugger to rdm when it's in it's 'wedged' state and capture a backtrace. Sampling several times reveals that we've always got Project::dependsOn near the top of the stack. I'm happy to look at this a bit more if you want to know anything more specific.

0 0x00007f311e6b119c in __GI___libc_malloc (bytes=24) at malloc.c:2924

1 0x00007f311f5e2e78 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

2 0x00000000005af963 in _M_init_functor (f=, functor=...) at /usr/include/c++/5/functional:1787

3 _M_init_functor (f=, functor=...) at /usr/include/c++/5/functional:1758

4 function<Project::dependsOn(uint32_t, uint32_t) const::<lambda(DependencyNode*)>, void, void> (__f=..., this=0x7ffc8ad02620) at /usr/include/c++/5/functional:2254

5 Project::dependsOn (this=0x27bedf0, source=2210, header=header@entry=777) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Project.cpp:1021

6 0x0000000000563eab in CompletionThread::isCached (this=, fileId=fileId@entry=777, project=std::shared_ptr (count 2, weak 3) 0x27bedf0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/CompletionThread.cpp:586

7 0x000000000047fcfd in Server::prepareCompletion (this=this@entry=0x24b14d0, query=std::shared_ptr (count 3, weak 0) 0x250f000, fileId=fileId@entry=777, project=std::shared_ptr (count 2, weak 3) 0x27bedf0)

at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:2416

8 0x000000000048cb2f in Server::diagnose (this=this@entry=0x24b14d0, query=std::shared_ptr (count 3, weak 0) 0x250f000, conn=std::shared_ptr (count 3, weak 2) 0x2a330e0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:979

9 0x0000000000495b76 in Server::handleQueryMessage (this=this@entry=0x24b14d0, message=std::shared_ptr (count 3, weak 0) 0x250f000, conn=std::shared_ptr (count 3, weak 2) 0x2a330e0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:712

10 0x0000000000495ea6 in Server::onNewMessage (this=0x24b14d0, message=..., connection=std::shared_ptr (count 3, weak 2) 0x2a330e0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/Server.cpp:372

11 0x00000000004f303b in operator() (__args#1=std::shared_ptr (expired, weak 0) 0x7ffc8ad02cc0, __args#0=std::shared_ptr (count 45870384, weak -1) 0x7ffc8ad02ca0, this=) at /usr/include/c++/5/functional:2267

12 operator()<std::shared_ptr&, std::shared_ptr&> (this=0x2a33160) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/SignalSlot.h:70

13 Connection::onDataAvailable(std::shared_ptr const&, Buffer&&) (this=0x2a330e0, client=..., buf=) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/Connection.cpp:154

14 0x0000000000514e3e in operator() (args#1=, args#0=..., this=0x2571998) at /usr/include/c++/5/functional:2267

15 operator()<std::shared_ptr&, Buffer> (this=0x2530ca0) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/SignalSlot.h:70

16 SocketClient::socketCallback (this=0x2530c50, f=, mode=1) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/SocketClient.cpp:685

17 0x00000000004fbcb0 in operator() (args#1=1, args#0=15, this=0x7ffc8ad07560) at /usr/include/c++/5/functional:2267

18 EventLoop::fireSocket (this=this@entry=0x24b1250, fd=15, mode=1) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/EventLoop.cpp:710

19 0x00000000004fcaa9 in EventLoop::processSocketEvents (this=this@entry=0x24b1250, events=events@entry=0x7ffc8ad077b0, eventCount=) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/EventLoop.cpp:851

20 0x00000000004fe77a in EventLoop::exec (this=0x24b1250, timeoutTime=timeoutTime@entry=-1) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rct/rct/EventLoop.cpp:964

21 0x000000000045cf6c in main (argc=, argv=) at /home/gfg/git/undo-code/instr/rtags-2.11/src/rdm.cpp:846

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/996#issuecomment-319067922, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSmgAcNEoRfumRpZKKoukqI1Tz1ICks5sTddjgaJpZM4OH9IK .

FinnG commented 7 years ago

Disabling completions would likely help somewhat. RTags can be chatty at times and every synchronous call will have a stack like this and will hang emacs until it completes.

Yes, completions are another feature that causes emacs to hang.

I should clarify, this isn't something that emacs/rdm recovers from. As far as I can tell it hangs indefinitely (I've only waited about a minute - but that seems like a reasonable amount of time to me!). I can only get control of emacs back with C-g. The only way to get rtags working again is to kill rdm with SIGKILL as it doesn't respond to a SIGTERM. The indefinite hang and lack of response to SIGTERM makes me think this is a bit more than rdm being resource hungry.

I would also recommend compiling rdm in release.

I would try building from source off master, but unfortunately I'm still blocked by #1014 (or was on Friday, I'll try rebuilding again when I get a chance).

Andersbakken commented 7 years ago

Hm. That is definitely interesting. I think the way to go forward then is to compile rtags in debug and attach with gdb when it happens. It sounds like it's hung somewhere.

Anders

On Tue, Aug 1, 2017 at 12:23 AM, Finn Grimwood notifications@github.com wrote:

Disabling completions would likely help somewhat. RTags can be chatty at times and every synchronous call will have a stack like this and will hang emacs until it completes.

Yes, completions are another feature that causes emacs to hang.

I should clarify, this isn't something that emacs/rdm recovers from. As far as I can tell it hangs indefinitely (I've only waited about a minute - but that seems like a reasonable amount of time to me!). I can only get control of emacs back with C-g. The only way to get rtags working again is to kill rdm with SIGKILL as it doesn't respond to a SIGTERM. The indefinite hang and lack of response to SIGTERM makes me think this is a bit more than rdm being resource hungry.

I would also recommend compiling rdm in release.

I would try building from source off master, but unfortunately I'm still blocked by #1014 https://github.com/Andersbakken/rtags/issues/1014 (or was on Friday, I'll try rebuilding again when I get a chance).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/996#issuecomment-319290059, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSiiXGqdLxfE38F-fQvhgdol6Ijmqks5sTtJagaJpZM4OH9IK .

benhsmith commented 5 years ago

I've seen this problem, too. Something else I've noticed is that after it happens the Emacs menu bar will become unresponsive. When I click a menu it flashes, but the menu doesn't drop down. This is on OSX.

t-mw commented 5 years ago

I was seeing this problem as long as I was launching rdm using (rtags-start-process-unless-running). It seems ok now that I'm running it in a separate shell.