Sublime Forum

Debug locked up sublime text instance

#1

So sublime is locked up and I can’t interact with the UI at all. top shows it pegged at 100%

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                 
19848 me   20   0 40.208g 0.038t 171176 R  99.0 61.8 260:33.41 sublime_text        

The plugin_host doesn’t seem to be doing anything:

me  19864  0.1  0.1 1037976 83676 ?       Sl   Nov27   3:24 /opt/sublime_text/plugin_host 19848

Running 3154 on Debian.

Is there a log I can tail to see what sublime is doing?

0 Likes

#2

Here is a backtrace, not sure how helpful it is without the symbols though

(gdb) thread apply all backtrace

Thread 9 (Thread 0x7fbfb6bd1700 (LWP 20862)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000006ae544 in ?? ()
#2  0x00007fbfdd343494 in start_thread (arg=0x7fbfb6bd1700) at pthread_create.c:333
#3  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 8 (Thread 0x7fbfb5f34700 (LWP 19865)):
#0  0x00007fbfdd34cb3a in __waitpid (pid=19864, stat_loc=0x7fbfb5f33edc, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1  0x0000000000636a88 in ?? ()
#2  0x0000000000892050 in ?? ()
#3  0x00007fbfdd343494 in start_thread (arg=0x7fbfb5f34700) at pthread_create.c:333
#4  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 7 (Thread 0x7fbfcffff700 (LWP 19863)):
#0  0x00007fbfdd34b536 in futex_abstimed_wait_cancelable (private=128, abstime=0x0, expected=0, futex_word=0x7fbfddd1b000)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x7fbfddd1b000, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007fbfdd34b5e4 in __new_sem_wait_slow (sem=0x7fbfddd1b000, abstime=0x0) at sem_waitcommon.c:181
#3  0x000000000063a54d in ?? ()
#4  0x000000000063a69b in ?? ()
#5  0x0000000000425d29 in ?? ()
#6  0x00007fbfdd343494 in start_thread (arg=0x7fbfcffff700) at pthread_create.c:333
#7  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 6 (Thread 0x7fbfcdffb700 (LWP 19854)):
#0  0x00007fbfdd34b536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x1b8f700)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x1b8f700, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007fbfdd34b5e4 in __new_sem_wait_slow (sem=0x1b8f700, abstime=0x0) at sem_waitcommon.c:181
#3  0x000000000063731a in ?? ()
#4  0x0000000000632212 in ?? ()
#5  0x0000000000632594 in ?? ()
#6  0x0000000000632544 in ?? ()
#7  0x00007fbfdd343494 in start_thread (arg=0x7fbfcdffb700) at pthread_create.c:333
#8  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 5 (Thread 0x7fbfce7fc700 (LWP 19853)):
#0  0x00007fbfdd34b536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x1b8f700)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x1b8f700, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007fbfdd34b5e4 in __new_sem_wait_slow (sem=0x1b8f700, abstime=0x0) at sem_waitcommon.c:181
#3  0x000000000063731a in ?? ()
#4  0x0000000000632212 in ?? ()
#5  0x0000000000632594 in ?? ()
#6  0x0000000000632544 in ?? ()
#7  0x00007fbfdd343494 in start_thread (arg=0x7fbfce7fc700) at pthread_create.c:333
#8  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 4 (Thread 0x7fbfceffd700 (LWP 19852)):
#0  0x00007fbfdd34b536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x1b8f780)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x1b8f780, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007fbfdd34b5e4 in __new_sem_wait_slow (sem=0x1b8f780, abstime=0x0) at sem_waitcommon.c:181
#3  0x000000000063731a in ?? ()
#4  0x000000000063e200 in ?? ()
#5  0x000000000063e334 in ?? ()
#6  0x00007fbfdd343494 in start_thread (arg=0x7fbfceffd700) at pthread_create.c:333
#7  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 3 (Thread 0x7fbfcf7fe700 (LWP 19851)):
#0  0x00007fbfdc83463d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fbfdd5a39f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fbfdd5a3d82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fbfd884f656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007fbfdd5cb3d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fbfdd343494 in start_thread (arg=0x7fbfcf7fe700) at pthread_create.c:333
#6  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7fbfd4d06700 (LWP 19849)):
#0  0x00007fbfdc83463d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fbfdd5a39f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fbfdd5a3b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fbfdd5a3b51 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#4  0x00007fbfdd5cb3d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fbfdd343494 in start_thread (arg=0x7fbfd4d06700) at pthread_create.c:333
#6  0x00007fbfdc83da8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x7fbfddec0dc0 (LWP 19848)):
#0  0x00000000006209b8 in ?? ()
#1  0x000000000061ff8d in ?? ()
#2  0x000000000061ffc7 in ?? ()
#3  0x00007fbfdd5a36aa in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fbfdd5a3a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fbfdd5a3d82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007fbfd674d3b7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#7  0x000000000061a2f3 in ?? ()
#8  0x000000000040b65b in ?? ()
#9  0x00007fbfdc7752b1 in __libc_start_main (main=0x40aa44, argc=1, argv=0x7ffe16bc3928, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7ffe16bc3918) at ../csu/libc-start.c:291
#10 0x000000000040a6b7 in ?? ()
0 Likes

#3

I think that if you kill plugin_host and Sublime Text start responding again, it means that some plugin from a package was doing a infinity loop, or triggered a deadlock:

  1. https://github.com/SublimeTextIssues/Core/issues/1463 Packages are allowed to hang Sublime Text Indefinitely
  2. https://github.com/SublimeTextIssues/Core/issues/1966 Deadlock/hang when batch deleting/creating settings files

Next time you can try to kill plugin_host and see if Sublime Text start responding again. This is what I do while writing a package and accidentally I write an infinity loop like:

        while True :
            print( 'bitch\n' )

Then I kill plugin_host and Sublime Text start responding again. Sadly, I need restart Sublime Text to restore the packages functionality.

0 Likes

#4

So I tried killing plugin_host and the the sublime_text process was still stuck in a loop. So i’m pretty sure it wasn’t a plugin,

0 Likes