search for: __kernel_vsyscall

Does anyone have any ideas why my recently updated * 1.2.5 system should spawn multiple * process at seemingly random intervals? Regards L:ee ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.f-secure.com/ -------------- next part -------------- An HTML attachment was scrubbed...

...ew Thread 0xb50ffb90 (LWP 22839)] [New Thread 0xb562cb90 (LWP 22838)] [New Thread 0xb567db90 (LWP 22837)] [New Thread 0xb56feb90 (LWP 22836)] [New Thread 0xb574fb90 (LWP 22835)] [New Thread 0xb5b4cb90 (LWP 22834)] [New Thread 0xb5b9db90 (LWP 22833)] [New Thread 0xb5c1eb90 (LWP 22832)] 0xffffe410 in __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 0xb7f2d676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb7f2dd28 in pthread_cond_wait at GLIBC_2.0 () from /lib/i686/cmov/libpthread.so.0 #3 0x0630b2d9 in os::PlatformEvent::park () from /usr/lib/jvm/java-6...

...hread debugging using libthread_db enabled] [New Thread -1208465712 (LWP 3028)] [New Thread -1370231920 (LWP 3754)] [New Thread -1338922096 (LWP 3303)] [New Thread -1402664048 (LWP 3301)] (no debugging symbols found) (no debugging symbols found) <snip, many identical lines deleted) 0x00cf6402 in __kernel_vsyscall () #0 0x00cf6402 in __kernel_vsyscall () #1 0x00127d7b in waitpid () from /lib/libpthread.so.0 #2 0x00654c26 in gnome_gtk_module_info_get () from /usr/lib/libgnomeui-2.so.0 #3 0x0805dc19 in POA_GNOME_Evolution_DataServer_InterfaceCheck__fini () #4 <signal handler called> #5 0x04191700 i...

...;t attach process 0008: error 5 warning: could not attach to 0008 Can't attach process 0008: error 5 warning: could not attach to 0008 Can't attach process 0008: error 5 warning: could not attach to 0008 Can't attach process 0008: error 5 warning: could not attach to 0008 0xf778342e __kernel_vsyscall+0xe in [vdso].so: int $0x80 Backtracing for thread 001f in process 000e (C:\windows\system32\services.exe): Backtrace: =>0 0xf778342e __kernel_vsyscall+0xe() in [vdso].so (0x00a4e598) 1 0xf75e3bcb __libc_read+0x4a() in libpthread.so.0 (0x00a4e598) 2 0x7bc77758 wait_reply+0x57(cookie=0xa4e72...

...K, 0^C <unfinished ...> 2. When we kill the application and generate a core file, Here is what gdb shows: Core was generated by ` <our application> 12 12 10.33.0.230 eth1 -1 0 3 fd5d:d50a:8c17:3300::e6'. Program terminated with signal 6, Aborted. #0 0x007c2430 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.i686 libgcc-4.4.7-3.el6.i686 libstdc++-4.4.7-3.el6.i686 (gdb) bt #0 0x007c2430 in __kernel_vsyscall () #1 0x008a8d8e in shmctl@@GLIBC_2.2 () from /lib/libc.so.6 #2 0x0847c13e in MpcMpSwms_SwibIfShmSegOpen (ps=<va...

I'm still getting duplicate process but the results of gdb are different. Can anyone shed any light onto what is causing this? (gdb) info threads 1 Thread 1091845040 (LWP 31287) 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt Thread 1 (Thread 1091845040 (LWP 31287)): #0 0xffffe410 in __kernel_vsyscall () #1 0x4004f13e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #2 0x4004be41 in _L_mutex_lock_191 () from /lib/tls/libpthread.so.0 #3 0x40224600 in _IO_wide_data_2 () from /lib...

http://bugs.freedesktop.org/show_bug.cgi?id=10927 Summary: segmentation fault in NVUploadToScreen, called from exaPutImage Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

...quot; and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Core was generated by `dovecot/auth'. Program terminated with signal 6, Aborted. #0 0xb7729430 in __kernel_vsyscall () #0 0xb7729430 in __kernel_vsyscall () No symbol table info available. #1 0xb7551751 in ?? () No symbol table info available. (gdb) quit I think my automatic debugger script needs to be fixed. -- Ralf Hildebrandt Gesch?ftsbereich IT | Abteilung Netzwerk Charit? - Universit?tsmedizin Berl...

Hi All, I'm facing a problem in icecast relay machines. I'm seeing frequently that some of the relay machines are crashing and generates core dump but the reason for the crash is not clear from the trace of the core. Here is how the gdb trace looks like: (gdb) bt #0 0xffffe435 in __kernel_vsyscall () #1 0xf742c607 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0xf742fa33 in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0xf7466e53 in ?? () from /lib/i386-linux-gnu/libc.so.6 #4 0xf747133a in ?? () from /lib/i386-linux-gnu/libc.so.6 #5 0xf7472ee9 in ?? () from /lib/i386-linux-gnu/...

Hi All, I'm facing a problem in icecast relay machines. I'm seeing frequently that some of the relay machines are crashing and generates core dump but the reason for the crash is not clear from the trace of the core. Here is how the gdb trace looks like: (gdb) bt #0 0xffffe435 in __kernel_vsyscall () #1 0xf742c607 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0xf742fa33 in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0xf7466e53 in ?? () from /lib/i386-linux-gnu/libc.so.6 #4 0xf747133a in ?? () from /lib/i386-linux-gnu/libc.so.6 #5 0xf7472ee9 in ?? () from /lib/i386-linux-gnu/...

...0] /usr/sbin/asterisk(pbx_substitute_variables_helper_full+0x29d)[0x81070dd] /usr/sbin/asterisk[0x810797a] /usr/sbin/asterisk[0x810a0a4] /usr/sbin/asterisk[0x810bc20] /usr/sbin/asterisk[0x814c92b] /lib/libpthread.so.0[0x4ef46b] /lib/libc.so.6(clone+0x5e)[0xe5fdbe] #0 0x00c6c402 in __kernel_vsyscall () (gdb) bt #0 0x00c6c402 in __kernel_vsyscall () #1 0x0019ad20 in raise () from /lib/libc.so.6 #2 0x0019c631 in abort () from /lib/libc.so.6 #3 0x001d2e6b in __libc_message () from /lib/libc.so.6 #4 0x001dd440 in _int_realloc () from /lib/libc.so.6 #5 0x001de377 in realloc () from /li...

...I am working with someone else's LLVM code, which is about 8 months old. Part of this pass involves AliasAnalysis, and I'm getting the above assertion when the pass completes. The dump is as follows: -------------------------------- Program received signal SIGABRT, Aborted. 0xf7fdf430 in __kernel_vsyscall () (gdb) bt #0 0xf7fdf430 in __kernel_vsyscall () #1 0xf602e921 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xf6031d52 in *__GI_abort () at abort.c:92 #3 0xf6027788 in *__GI___assert_fail (assertion=0xf78ef62c "AA && \"AA didn't call InitializeAlias...

...>> about 8 >> months old. Part of this pass involves AliasAnalysis, and I'm getting the >> above assertion when the pass completes. The dump is as follows: >> >> -------------------------------- >> Program received signal SIGABRT, Aborted. 0xf7fdf430 in __kernel_vsyscall >> () (gdb) bt #0 0xf7fdf430 in __kernel_vsyscall () #1 0xf602e921 in >> *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 >> 0xf6031d52 in *__GI_abort () at abort.c:92 #3 0xf6027788 in >> *__GI___assert_fail (assertion=0xf78ef62c "AA&& \&quo...

...one else's LLVM code, which is about 8 > months old. Part of this pass involves AliasAnalysis, and I'm getting the > above assertion when the pass completes. The dump is as follows: > > -------------------------------- > Program received signal SIGABRT, Aborted. 0xf7fdf430 in __kernel_vsyscall > () (gdb) bt #0 0xf7fdf430 in __kernel_vsyscall () #1 0xf602e921 in > *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 > 0xf6031d52 in *__GI_abort () at abort.c:92 #3 0xf6027788 in > *__GI___assert_fail (assertion=0xf78ef62c "AA&& \"AA didn't...

...attached - interrupt to quit fcntl64(14, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=3684, len=1} <unfinished ...> Process 6414 detached # The file descriptor 14 corresponds to /var/lib/samba/locking.tdb file. A backtrace using gdb from one stalled daemon: (gdb) bt #0 0x00faf402 in __kernel_vsyscall () #1 0x003dbd7a in fcntl () from /lib/libc.so.6 #2 0x008e50eb in tdb_set_lock_alarm () from /usr/sbin/smbd #3 0x008e5307 in tdb_set_lock_alarm () from /usr/sbin/smbd #4 0x008e5868 in tdb_chainlock () from /usr/sbin/smbd #5 0x00880da8 in get_share_mode_lock () from /usr/sbin/smbd #6 0x0088167...

...am working with someone else's LLVM code, which is about 8 months old. Part of this pass involves AliasAnalysis, and I'm getting the above assertion when the pass completes. The dump is as follows: -------------------------------- Program received signal SIGABRT, Aborted. 0xf7fdf430 in __kernel_vsyscall () (gdb) bt #0 0xf7fdf430 in __kernel_vsyscall () #1 0xf602e921 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xf6031d52 in *__GI_abort () at abort.c:92 #3 0xf6027788 in *__GI___assert_fail (assertion=0xf78ef62c "AA && \"AA didn't call InitializeA...

...ded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 #0 0xffffe410 in __kernel_vsyscall () (gdb) bt full #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7edb7d0 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7edcea3 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x080b71cd in default_fatal_finish (type=<valu...

...daemon-reloadsystemctl restart dovecot Nope, I'm on a debian 7, without systemd. Anyway, I've resolved the issue: I had to set fs.suid_dumpable BEFORE starting dovecot. I've got a core dump, and here is the backtrace. Let me know if you want the core file. gdb) bt #0 0xb76e4428 in __kernel_vsyscall () #1 0xb74636c1 in raise () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb7466af2 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #3 0xb76485ae in default_fatal_finish (type=<optimized out>, status=status at entry=0) at failures.c:201 #4 0xb7648641 in i_internal_fatal_hand...

...[vdso] b80ce000-b80cf000 r--p 0001a000 08:05 2122026 /lib/ld-2.8.90.so b80cf000-b80d0000 rw-p 0001b000 08:05 2122026 /lib/ld-2.8.90.so bfeba000-bfecf000 rw-p bffeb000 00:00 0 [stack] Program received signal SIGABRT, Aborted. [Switching to Thread 0xb7dc56c0 (LWP 25458)] 0xb80cd430 in __kernel_vsyscall () (gdb) bt #0 0xb80cd430 in __kernel_vsyscall () #1 0xb7df28a0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7df4268 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7e3016d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7ec16d8 in __fortify_fail () from /lib/tls/i686/cmov/libc.so....

...ound) > [Thread debugging using libthread_db enabled] [New Thread 1077480288 > (LWP 7785)] (no debugging symbols found) (no debugging symbols found) > (no debugging symbols found) (no debugging symbols found) (no > debugging symbols found) (no debugging symbols found) 0xffffe410 in > __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 > 0x40202d93 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 > 0x40198d52 in system () from /lib/tls/i686/cmov/libc.so.6 #3 > 0x080d4dc7 in smb_panic () #4 0x080c29fc in dbgtext () #5 <signal > handler called> #6 0x08074e95 in...