When I try to start or source neovim/vim/vi, I'll get follow messages.
syntax_on #1
did_load_filetypes #1
ft_ignore_pat \.\(Z\|gz\|bz2\|zip\|tgz\)$
b:changedtick #1
v:beval_winid #0
v:version #800
v:t_list #3
v:beval_winnr #0
v:errors []
v:lnum #0
v:hlsearch #1
v:t_channel #9
v:oldfiles [
v:dying #0
v:windowid #0
v:mouse_winid #0
v:lang C.UTF-8
v:t_none #7
v:count #0
v:progpath /usr/bin/vim.basic
v:true v:true
v:t_string #1
v:none v:none
v:progname vi
v:t_bool #6
v:t_number #0
v:vim_did_enter #0
v:cmdbang #0
v:foldlevel #0
v:t_func #2
v:ctype C.UTF-8
v:t_job #8
v:prevcount #0
v:register "
v:mouse_win #0
v:count1 #0
v:foldstart #0
v:foldend #0
v:profiling #0
v:t_float #5
v:null v:null
v:beval_col #0
v:beval_lnum #0
v:mouse_lnum #0
v:completed_item {}
v:t_dict #4
v:false v:false
v:beval_bufnr #0
v:shell_error #0
v:testing #0
v:lc_time C.UTF-8
v:searchforward #1
v:event {}
v:mouse_col #0
Press ENTER or type command to continue
I don't know what's happend. I was tried to setup some vim key map befor I saw those messages first.
After that, I tried to off all plugin, and it's dosen`t work.
You probably have a line in your .vimrc / .config/nvim/init.vim, or some file included by them, that just says let. Maybe you got distracted in the middle of writing something else?
Related
When I launch vim it echoes a lot of variables (from my .vimrc I think) to the shell, before asking to continue. Why is this happening and what can I do to stop it?
Here's an example:
ycm_cache_omnifunc #0
oceanic_next_terminal_bold #1
ycm_seed_identifiers_with_syntax #1
vundle#lazy_load #0
vundle#updated_bundles []
terminal_color_background #1b2b34
terminal_color_12 #6699cc
vundle#bundle_dir /home/username/.vim/bundle
syntax_on #1
did_load_filetypes #1
ycm_confirm_extra_conf #0
...
v:errmsg E216: No such group or event: filetypedetect *
v:beval_lnum #0
v:mouse_lnum #0
v:completed_item {}
v:t_dict #4
v:false v:false
v:beval_bufnr #0
v:shell_error #0
v:testing #0
v:lc_time en_US.UTF-8
v:searchforward #1
v:event {}
v:mouse_col #0
Press ENTER or type command to continue
It then launches fine.
I have some complicated problem (by complicated I mean that I couldn't find a solution within a few hours of researching) and the problem is:
I submitted large amount of scripts to run (on an SGE cluster), some of those scripts generated core.# files (core dump files). I figured I could open those files with gdb, now when I simply open the core.# file I see this:
(the last few lines of the gdb output)
Core was generated by `/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004a554b in ?? ()
"/4thExp/core.82912" is a core file.
Please specify an executable to debug.
Now to my question - I need to find what was the arguments to the program that caused the crash.
The output mentioned above shows only the beginning of the command that caused the crash: "Core was generated by `/groups/nshomron/artemd/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'."
If I could see the rest of the command I would solve my problem, but after hours of searching online and checking gdb manual I couldn't find anything useful. I tried loading gdb with the program that caused the crash "gdb ..../graphmap core.#" but still I got only the beginning of the faulty command and couldn't get anything else.
Any help suggestion would be very appreciated.
Update: As the user #ks1322 suggested - I looked closely at the threads.
First I executed "info threads" and got the output:
(gdb) info threads
24 Thread 0x2b29409bd700 (LWP 82927) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
23 Thread 0x2b29401b9700 (LWP 82923) 0x00000031d00f820e in __lll_lock_wait_private () from /lib64/libc.so.6
* 22 Thread 0x2b29403ba700 (LWP 82924) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
21 Thread 0x2b29413c2700 (LWP 82932) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
20 Thread 0x2b293fbb6700 (LWP 82920) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
19 Thread 0x2b293fdb7700 (LWP 82921) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
18 Thread 0x2b2940bbe700 (LWP 82928) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
17 Thread 0x2b293f3b2700 (LWP 82916) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
16 Thread 0x2b29411c1700 (LWP 82931) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
15 Thread 0x2b2940dbf700 (LWP 82929) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
14 Thread 0x2b29419c5700 (LWP 82935) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
13 Thread 0x2b293efb0700 (LWP 82914) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
12 Thread 0x2b293f7b4700 (LWP 82918) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
11 Thread 0x2b29407bc700 (LWP 82926) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
10 Thread 0x2b293f9b5700 (LWP 82919) 0x00000031d00f820e in __lll_lock_wait_private () from /lib64/libc.so.6
9 Thread 0x2b29415c3700 (LWP 82933) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
8 Thread 0x2b29405bb700 (LWP 82925) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
7 Thread 0x2b292ea08be0 (LWP 82912) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
6 Thread 0x2b293ffb8700 (LWP 82922) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
5 Thread 0x2b293edaf700 (LWP 82913) 0x00000031d0045063 in vfprintf () from /lib64/libc.so.6
4 Thread 0x2b2940fc0700 (LWP 82930) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
3 Thread 0x2b293f1b1700 (LWP 82915) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
2 Thread 0x2b29417c4700 (LWP 82934) 0x0000000000412bd6 in obtainAlignment(unsigned char const*, unsigned char const*, int, unsigned char const*, unsigned char const*, int, int, int, unsigned char**, int*) ()
1 Thread 0x2b293f5b3700 (LWP 82917) 0x00000000004a554b in GraphMap::ProcessKmerCacheFriendly_(signed char*, long, ScoreRegistry*, MappingData*, Index*, SingleSequence const*, ProgramParameters const*) ()
It didn't tell me very much so I continued to look for a "main thread". I switched to each thread, one by one, and executed "info stack". The only thread containing something relevant was thread 7. the info stack output:
(gdb) thread 7
[Switching to thread 7 (Thread 0x2b292ea08be0 (LWP 82912))]#0 0x00000031d00ac6aa in times () from /lib64/libc.so.6
(gdb) info stack
#0 0x00000031d00ac6aa in times () from /lib64/libc.so.6
#1 0x00000031d009bcba in clock () from /lib64/libc.so.6
#2 0x00000000004ccaed in GraphMap::RegionSelectionNoCopy_(long, MappingData*, std::vector<Index*, std::allocator<Index*> >, SingleSequence const*, ProgramParameters const*) ()
#3 0x00000000004c3544 in GraphMap::ProcessRead(MappingData*, std::vector<Index*, std::allocator<Index*> >, SingleSequence const*, ProgramParameters const*, EValueParams const*) ()
#4 0x00000000004adf43 in GraphMap::ProcessSequenceFileInParallel ()
#5 0x00002b292e7f096f in GOMP_parallel () from /share/apps/gcc/gcc530/lib64/libgomp.so.1
#6 0x00000000004b0b08 in GraphMap::ProcessSequenceFileInParallel(ProgramParameters*, SequenceFile*, long*, _IO_FILE*, long*, long*) ()
#7 0x00000000004b1796 in GraphMap::ProcessReadsFromSingleFile(ProgramParameters&, _IO_FILE*) ()
#8 0x00000000004b281e in GraphMap::Run(ProgramParameters&) ()
#9 0x00000000005087fe in main ()
But I got stuck again from here (short reminder: my goal is to find the full command that crushed the execution, the beginning of which is displayed on the first page of gdb like this:
Core was generated by `/tools/graphmap/bin/Linux-x64/graphmap align
--overlappe'.
Any help from here would be very appreciated.
Final Update, problem solved: I followed #ks1322 advice and went to this stack overflow thread and then I repeated what was described in the first answer and was able to get the arguments.
(short overview of what I understood with my limited knowledge of working with gdb: First you should check what threads were running the task, you can do it with "info threads" then you need to check which thread has "main" in it's stack, I did it by switching threads one by one with "thread #" and printing the stack with "info stack" until I found the thread that had main in it. in my case it was shown like this in the "info stack" #9 0x00000000005087fe in main ()". Then according to the instructions in the linked thread, I executed "set backtrace past-main" then "bt" and then changed frame to the frame containing "in _start ()" with the command "frame #". Almost done, now I ran the command "x/8gx $rsp+8" with showed few four lines with 2 addressees in each line. In my case the second line looked like this "0x7ffe38f872d8: 0x00007ffe38f88c35 0x00007ffe38f88c73" and now if everything was right this address can contain one of the arguments of the command that caused the crush, you can check it with "x/s" command like so: "x/s 0x00007ffe38f88c35" and it prints the argument. Important note: I had a lot of arguments so I needed to go to later addressees that did not show in the "x/8gx $rsp+8" command, I noticed that the addresses are incremented by constant value (3 in hex) so I kept manually in a calculator adding "3" to the address and checking the address with x/s until I got to my wanted argument)
Very messy solution and I hope someone could find an easier solution but that is all I could find.
Big thanks to #ks1322 who cleared up things for me and guided me to the solution.
You can load core dump with matching binary (the one for which core dump was generated) and print argv values in the frame where main function resides.
Something like this:
gdb /tools/graphmap/bin/Linux-x64/graphmap /4thExp/core.82912
Then go up in stack trace to initial frame where int main(int argc, char *argv[]) resides. Now you can print the number of arguments and their values from gdb prompt.
Update:
It appears that your binary is multithreaded and crash happened in some auxiliary thread. You should therefore find main thread and switch to it. Here is an example of how to do it for Firefox with many threads:
(gdb) t a a bt -1
Thread 59 (Thread 0x7f691deff700 (LWP 25924)):
#12 0x00007f69dce93f6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
..........
..........
many threads are listed here
..........
..........
Thread 1 (Thread 0x7f69de01a740 (LWP 4143)):
#17 0x000056374cb38817 in main ()
(gdb) t 1
[Switching to thread 1 (Thread 0x7f69de01a740 (LWP 4143))]
#0 0x00007f69dce8800d in poll () at ../sysdeps/unix/syscall-template.S:84
84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Now gdb is switched to main thread (Thread 1).
My OS is RHEL 7, and I run a simple Go program:
package main
import (
"time"
)
func main() {
time.Sleep(1000 * time.Second)
}
During its running, I check the thread count of process:
# cat /proc/13858/status | grep Thread
Threads: 5
While using the pstack command shipped on RHEL, it only prints one thread's stack:
# pstack 13858
Thread 1 (process 13858):
#0 runtime.futex () at /usr/local/go/src/runtime/sys_linux_amd64.s:307
#1 0x0000000000422580 in runtime.futexsleep (addr=0x4c7af8 <runtime.timers+24>, val=0, ns=999999997446) at /usr/local/go/src/runtime/os1_linux.go:57
#2 0x000000000040b07b in runtime.notetsleep_internal (n=0x4c7af8 <runtime.timers+24>, ns=999999997446, ~r2=255) at /usr/local/go/src/runtime/lock_futex.go:174
#3 0x000000000040b1e6 in runtime.notetsleepg (n=0x4c7af8 <runtime.timers+24>, ns=999999997446, ~r2=false) at /usr/local/go/src/runtime/lock_futex.go:206
#4 0x000000000043e5de in runtime.timerproc () at /usr/local/go/src/runtime/time.go:209
#5 0x0000000000451001 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1998
#6 0x0000000000000000 in ?? ()
Why does pstack only print one thread's content?
P.S.: The pstack script is here:
#!/bin/sh
if test $# -ne 1; then
echo "Usage: `basename $0 .sh` <process-id>" 1>&2
exit 1
fi
if test ! -r /proc/$1; then
echo "Process $1 not found." 1>&2
exit 1
fi
# GDB doesn't allow "thread apply all bt" when the process isn't
# threaded; need to peek at the process to determine if that or the
# simpler "bt" should be used.
backtrace="bt"
if test -d /proc/$1/task ; then
# Newer kernel; has a task/ directory.
if test `/bin/ls /proc/$1/task | /usr/bin/wc -l` -gt 1 2>/dev/null ; then
backtrace="thread apply all bt"
fi
elif test -f /proc/$1/maps ; then
# Older kernel; go by it loading libpthread.
if /bin/grep -e libpthread /proc/$1/maps > /dev/null 2>&1 ; then
backtrace="thread apply all bt"
fi
fi
GDB=${GDB:-/usr/bin/gdb}
# Run GDB, strip out unwanted noise.
# --readnever is no longer used since .gdb_index is now in use.
$GDB --quiet -nx $GDBARGS /proc/$1/exe $1 <<EOF 2>&1 |
set width 0
set height 0
set pagination no
$backtrace
EOF
/bin/sed -n \
-e 's/^\((gdb) \)*//' \
-e '/^#/p' \
-e '/^Thread/p'
pstack uses gdb. This is a quote from golang doc (https://golang.org/doc/gdb):
GDB does not understand Go programs well. The stack management,
threading, and runtime contain aspects that differ enough from the
execution model GDB expects that they can confuse the debugger, even
when the program is compiled with gccgo. As a consequence, although
GDB can be useful in some situations, it is not a reliable debugger
for Go programs, particularly heavily concurrent ones.
4 out of 5 threads that you see in /proc are created even before you program enters main. I assume that golang runtime creates them.
Why does pstack only print one thread's content?
Judging from output of strace for gdb I see that gdb actually tries to attach to them but after something goes wrong and gdb does not try to inspect these threads. These are syscalls that gdb issued for these runtime threads but due to unknown reason decided stopped investigating them immediately:
5072 ptrace(PTRACE_ATTACH, 5023, 0, 0) = 0
5072 --- SIGCHLD (Child exited) # 0 (0) ---
5072 rt_sigreturn(0x11) = 0
5072 ptrace(PTRACE_ATTACH, 5024, 0, 0) = 0
5072 --- SIGCHLD (Child exited) # 0 (0) ---
5072 rt_sigreturn(0x11) = 0
5072 ptrace(PTRACE_ATTACH, 5025, 0, 0) = 0
5072 --- SIGCHLD (Child exited) # 0 (0) ---
5072 rt_sigreturn(0x11) = 0
However you can inspect them yourself. It seems that these threads belong to golang runtime
$ pstack 5094
Thread 1 (process 5094):
#0 0x0000000000459243 in runtime.futex ()
#1 0x00000000004271e0 in runtime.futexsleep ()
#2 0x000000000040d55b in runtime.notetsleep_internal ()
#3 0x000000000040d64b in runtime.notetsleep ()
#4 0x0000000000435677 in runtime.sysmon ()
#5 0x000000000042e6cc in runtime.mstart1 ()
#6 0x000000000042e5d2 in runtime.mstart ()
#7 0x00000000004592b7 in runtime.clone ()
#8 0x0000000000000000 in ?? ()
$ pstack 5095
Thread 1 (process 5095):
#0 0x0000000000459243 in runtime.futex ()
#1 0x0000000000427143 in runtime.futexsleep ()
#2 0x000000000040d3f4 in runtime.notesleep ()
#3 0x000000000042f6eb in runtime.stopm ()
#4 0x0000000000430a79 in runtime.findrunnable ()
#5 0x00000000004310ff in runtime.schedule ()
#6 0x000000000043139b in runtime.park_m ()
#7 0x0000000000455acb in runtime.mcall ()
#8 0x000000c820021500 in ?? ()
#9 0x0000000000000000 in ?? ()
$ pstack 5096
Thread 1 (process 5096):
#0 0x0000000000459243 in runtime.futex ()
#1 0x0000000000427143 in runtime.futexsleep ()
#2 0x000000000040d3f4 in runtime.notesleep ()
#3 0x000000000042f6eb in runtime.stopm ()
#4 0x000000000042fff7 in runtime.startlockedm ()
#5 0x0000000000431147 in runtime.schedule ()
#6 0x000000000043139b in runtime.park_m ()
#7 0x0000000000455acb in runtime.mcall ()
#8 0x000000c820020000 in ?? ()
Update for gdb 8.0
pstack that uses gdb 8.0 correctly prints backtraces for all threas. The command looks like:
$ GDB=$HOME/bin/gdb pstack $(pidof main)
And here is its output (shortened):
$ GDB=$HOME/bin/gdb pstack $(pidof main) | egrep "^Thread"
Thread 4 (LWP 18335):
Thread 3 (LWP 18334):
Thread 2 (LWP 18333):
Thread 1 (LWP 18332):
When you're passing LWP/thread id to pstack you get a stack of that thread only. Try to pass a PID of the process to pstack and you'll get stacks of all its threads. You may get a PID or Tgid (thread group id) of the process: cat /proc/13858/status | grep Tgid. To get all LWPs created by your process you may run ps -L <PID>
I was trying to debug a deadlock issue in my code using gdb. When the program locked up, I attached to it with gdb to see what the threads were doing. For some reason, I cannot obtain backtraces for threads other than the current one:
(gdb) bt
#0 0xb774dcb0 in ?? ()
#1 0x8420e178 in TableCollect
#2 0x84200c12 in main
(gdb) thread apply all bt
Thread 3 (Thread 0xb6becb40 (LWP 18937)):
#0 0xb774dcb0 in ?? ()
#1 0x000d6ee6 in ?? ()
Thread 2 (Thread 0xb1f5eb40 (LWP 18939)):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x5:
#0 0xb774dcb0 in ?? ()
Cannot access memory at address 0x5
(gdb) info threads
Id Target Id Frame
3 Thread 0xb6becb40 (LWP 18937) "loader.elf" 0xb774dcb0 in ?? ()
2 Thread 0xb1f5eb40 (LWP 18939) "Tuner" 0xb774dcb0 in ?? ()
* 1 Thread 0xb6bed700 (LWP 18936) "loader.elf" 0xb774dcb0 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0xb1f5eb40 (LWP 18939))]
#0 0xb774dcb0 in ?? ()
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x5:
#0 0xb774dcb0 in ?? ()
Cannot access memory at address 0x5
(gdb) thread 3
[Switching to thread 3 (Thread 0xb6becb40 (LWP 18937))]
#0 0xb774dcb0 in ?? ()
(gdb) bt
#0 0xb774dcb0 in ?? ()
#1 0x000d6ee6 in ?? ()
ninja#vm:build$ cat /proc/`pidof loader.elf`/maps | grep b774d
b774b000-b774d000 r--p 00000000 00:00 0 [vvar]
b774d000-b774f000 r-xp 00000000 00:00 0 [vdso]
So it looks like all threads are inside a system call? That's likely since I'm expecting them all to be stuck on ptread_mutex_lock, but why don't I have valid stack frames below that? Why the 0x5 address for thread 2? And why does thread 3 have 0xd6ee6 on the stack, which isn't even mentioned in the memory map?
Although Linux doesn't provide pstack as Solaris does, RedHat provides a script can do the same thing:
#!/bin/bash
if test $# -ne 1; then
echo "Usage: `basename $0 .sh` <process-id>" 1>&2
exit 1
fi
if test ! -r /proc/$1; then
echo "Process $1 not found." 1>&2
exit 1
fi
# GDB doesn't allow "thread apply all bt" when the process isn't
# threaded; need to peek at the process to determine if that or the
# simpler "bt" should be used.
backtrace="bt"
if test -d /proc/$1/task ; then
# Newer kernel; has a task/ directory.
if test `/bin/ls /proc/$1/task | /usr/bin/wc -l` -gt 1 2>/dev/null ; then
backtrace="thread apply all bt"
fi
elif test -f /proc/$1/maps ; then
# Older kernel; go by it loading libpthread.
if /bin/grep -e libpthread /proc/$1/maps > /dev/null 2>&1 ; then
backtrace="thread apply all bt"
fi
fi
GDB=${GDB:-/usr/bin/gdb}
if $GDB -nx --quiet --batch --readnever > /dev/null 2>&1; then
readnever=--readnever
else
readnever=
fi
# Run GDB, strip out unwanted noise.
$GDB --quiet $readnever -nx /proc/$1/exe $1 <<EOF 2>&1 |
$backtrace
EOF
/bin/sed -n \
-e 's/^(gdb) //' \
-e '/^#/p' \
-e '/^Thread/p'
Executing the script in Suse:
linux:~ # pstack 7286
Thread 3 (Thread 0x7f7c074b5700 (LWP 7287)):
#0 0x00007f7c055f7a9d in read () from /lib64/libpthread.so.0
#1 0x00007f7c050a3b76 in ?? () from /usr/lib64/libxenstore.so.3.0
#2 0x00007f7c050a3c2f in ?? () from /usr/lib64/libxenstore.so.3.0
#3 0x00007f7c050a3f72 in ?? () from /usr/lib64/libxenstore.so.3.0
#4 0x00007f7c055f10a4 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f7c03c9104d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f7bfe4b0700 (LWP 7288)):
#0 0x00007f7c055f505f in pthread_cond_wait##GLIBC_2.3.2 ()
#1 0x00007f7c07199d99 in ?? ()
#2 0x00007f7c0709a213 in ?? ()
#3 0x00007f7c0709a610 in ?? ()
#4 0x00007f7c055f10a4 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f7c03c9104d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f7c07483980 (LWP 7286)):
#0 0x00007f7c03c88cdf in ppoll () from /lib64/libc.so.6
#1 0x00007f7c07060ec9 in ?? ()
#2 0x00007f7c07026654 in ?? ()
#3 0x00007f7c06edcb36 in ?? ()
#4 0x00007f7c03bcdb05 in __libc_start_main () from /lib64/libc.so.6
#5 0x00007f7c06ee0eec in ?? ()
My question is how to resolve the function name from the address? such as 0x00007fe4ab73eb36. I know maybe through installing debug-info packages, but how to know install which packages?
Update:
According to Mark Plotnick's comments, I use the following command to get which debuginfo packages are lacked:
linux:~ # gdb --quiet -nx --readnever /proc/7286/exe 7286
......
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.19-31.5.x86_64 ......
After installing all need debuginfo packages, the symbols can be resolved:
linux:~ # pstack 7286
Thread 3 (Thread 0x7f7c074b5700 (LWP 7287)):
#0 0x00007f7c055f7a9d in read () from /lib64/libpthread.so.0
#1 0x00007f7c050a3b76 in read_all.part.1.constprop ()
#2 0x00007f7c050a3c2f in read_message.constprop ()
#3 0x00007f7c050a3f72 in read_thread () from /usr/lib64/libxenstore.so.3.0
#4 0x00007f7c055f10a4 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f7c03c9104d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f7bfe4b0700 (LWP 7288)):
#0 0x00007f7c055f505f in pthread_cond_wait##GLIBC_2.3.2 ()
#1 0x00007f7c07199d99 in qemu_cond_wait ()
#2 0x00007f7c0709a213 in vnc_worker_thread_loop ()
#3 0x00007f7c0709a610 in vnc_worker_thread ()
#4 0x00007f7c055f10a4 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f7c03c9104d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f7c07483980 (LWP 7286)):
#0 0x00007f7c03c88cdf in ppoll () from /lib64/libc.so.6
#1 0x00007f7c07060ec9 in qemu_poll_ns ()
#2 0x00007f7c07026654 in main_loop_wait ()
#3 0x00007f7c06edcb36 in main ()
But "objdump -t /proc/7286/exe | grep main" outputs nothing:
linux:~ # objdump -t /proc/7286/exe | grep main
linux:~ #