| View previous topic :: View next topic |
| Author |
Message |
Saundersx
Apprentice
Joined: 11 Apr 2005
Posts: 290
|
 Posted: Wed Jan 02, 2019 7:51 am Post subject: kodi-18.0_rc4 segfaults |
 |
|
kodi now segfaults when I launch it
| Code: | kodi-x11[7041]: segfault at 0 ip 00007f9bde5a02b6 sp 00007ffe9ec498a8 error 4 in libc-2.28.so[7f9bde521000+15c000]
[ 91.378785] Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83 |
Haven't looked into it too much yet but it started right after upgrading to glibc-2.28-r4 . I recompiled kodi and no change. |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Thu Jan 03, 2019 2:36 am Post subject: |
|
|
| Please rebuild kodi and glibc with debug symbols, then use gdb to obtain a backtrace of the crash. |
|
| Back to top |
|
|
Saundersx
Apprentice
Joined: 11 Apr 2005
Posts: 290
|
| Posted: Thu Jan 03, 2019 5:34 am Post subject: |
|
|
from kodi's own log files, should help
| Code: | ################ SYSTEM INFO ################
Date: Thu Jan 3 00:49:03 AST 2019
Kodi Options:
Arch: x86_64
Kernel: Linux 4.20.0 #1 SMP PREEMPT Wed Jan 2 03:17:56 AST 2019
Release: Gentoo
############## END SYSTEM INFO ##############
############### STACK TRACE #################
=====> Core file: /home/hazelnut/.kodi/core (2019-01-03 00:49:02.207902472 -0400)
=========================================
[New LWP 28655]
[New LWP 28659]
[New LWP 28680]
[New LWP 28681]
[New LWP 28672]
[New LWP 28683]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib64/kodi/kodi-x11'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f95f754e2b6 in ?? () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f95ef8dce80 (LWP 28655))]
Thread 6 (Thread 0x7f95ed292700 (LWP 28683)):
#0 0x00007f95f75a8633 in poll () from /lib64/libc.so.6
#1 0x00007f95fbb21811 in ?? () from /usr/lib64/libpulse.so.0
#2 0x00007f95fbb12e60 in pa_mainloop_poll () from /usr/lib64/libpulse.so.0
#3 0x00007f95fbb134d0 in pa_mainloop_iterate () from /usr/lib64/libpulse.so.0
#4 0x00007f95fbb13570 in pa_mainloop_run () from /usr/lib64/libpulse.so.0
#5 0x00007f95fbb21749 in ?? () from /usr/lib64/libpulse.so.0
#6 0x00007f95f6f03417 in ?? () from /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#7 0x00007f95fbf635ea in start_thread () from /lib64/libpthread.so.0
#8 0x00007f95f75b4e8f in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f95eea95700 (LWP 28672)):
#0 0x00007f95f75a3eb0 in read () from /lib64/libc.so.6
#1 0x00007f95f6c3c063 in ?? () from /usr/lib64/libnvidia-tls.so.415.25
#2 0x00007f95fbb695f6 in lirc_nextcode () from /usr/lib64/liblirc_client.so.0
#3 0x00005607f199f3d8 in CLirc::Process() ()
#4 0x00005607f1cac0dd in CThread::Action() ()
#5 0x00005607f1cacf36 in CThread::staticThread(void*) ()
#6 0x00007f95fbf635ea in start_thread () from /lib64/libpthread.so.0
#7 0x00007f95f75b4e8f in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f95eda93700 (LWP 28681)):
#0 0x00007f95fbf6a4b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f95fbb21e47 in pa_threaded_mainloop_wait () from /usr/lib64/libpulse.so.0
#2 0x00005607f251dc3c in CAESinkPULSE::AddPackets(unsigned char**, unsigned int, unsigned int) ()
#3 0x00005607f250248f in ActiveAE::CActiveAESink::OutputSamples(ActiveAE::CSampleBuffer*) ()
#4 0x00005607f2505815 in ActiveAE::CActiveAESink::StateMachine(int, Actor::Protocol*, Actor::Message*) ()
#5 0x00005607f2506639 in ActiveAE::CActiveAESink::Process() ()
#6 0x00005607f1cac0dd in CThread::Action() ()
#7 0x00005607f1cacf36 in CThread::staticThread(void*) ()
#8 0x00007f95fbf635ea in start_thread () from /lib64/libpthread.so.0
#9 0x00007f95f75b4e8f in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f95ee294700 (LWP 28680)):
#0 0x00007f95fbf6a88a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00005607f24fbe1a in ActiveAE::CActiveAE::Process() ()
#2 0x00005607f1cac0dd in CThread::Action() ()
#3 0x00005607f1cacf36 in CThread::staticThread(void*) ()
#4 0x00007f95fbf635ea in start_thread () from /lib64/libpthread.so.0
#5 0x00007f95f75b4e8f in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f95ef296700 (LWP 28659)):
#0 0x00007f95fbf6a4b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f95f737bdec in __gthread_cond_wait (__mutex=<optimized out>, __cond=<optimized out>) at /tmp/portage/portage/sys-devel/gcc-7.4.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:864
#2 std::condition_variable::wait (this=<optimized out>, __lock=...) at /tmp/portage/portage/sys-devel/gcc-7.4.0/work/gcc-7.4.0/libstdc++-v3/src/c++11/condition_variable.cc:53
#3 0x00005607f23cb58e in ANNOUNCEMENT::CAnnouncementManager::Process() ()
#4 0x00005607f1cac0dd in CThread::Action() ()
#5 0x00005607f1cacf36 in CThread::staticThread(void*) ()
#6 0x00007f95fbf635ea in start_thread () from /lib64/libpthread.so.0
#7 0x00007f95f75b4e8f in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f95ef8dce80 (LWP 28655)):
#0 0x00007f95f754e2b6 in ?? () from /lib64/libc.so.6
#1 0x00005607f1ca96e5 in LogGraphicsInfo() ()
#2 0x00005607f1978f2b in CRenderSystemGL::InitRenderSystem() ()
#3 0x00005607f1faba03 in CApplication::InitWindow(RESOLUTION) ()
#4 0x00005607f1fb5a07 in CApplication::CreateGUI() ()
#5 0x00005607f1cd8ad1 in XBMC_Run ()
#6 0x00005607f176e067 in main ()
############# END STACK TRACE ############### |
|
|
| Back to top |
|
|
Saundersx
Apprentice
Joined: 11 Apr 2005
Posts: 290
|
| Posted: Thu Jan 03, 2019 11:38 pm Post subject: |
|
|
| Got around to rebuilding it with debug enabled and of course it works now... I'll try removing debug later and see if it goes back to crashing. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Fri Jan 04, 2019 2:42 am Post subject: |
|
|
| LogGraphicsInfo called an unknown libc function in a way that caused that function to crash. Identifying the called function could be very helpful. Debug information from glibc would show this. We could also try to infer it if we had line number information from the caller. |
|
| Back to top |
|
|
Saundersx
Apprentice
Joined: 11 Apr 2005
Posts: 290
|
| Posted: Fri Jan 04, 2019 6:58 am Post subject: |
|
|
| No luck. Recompiled without debug, back to crashing, recompiled again with debug, no crash. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sat Jan 05, 2019 1:57 am Post subject: |
|
|
That is a nasty bug. Toggling debug symbols for the program should have no effect on bug reproducibility. What debug settings did you use that cause it to start/stop failing?
You could try instrumenting LogGraphicsInfo and manually tracing how far it gets before it calls a glibc function that dies. |
|
| Back to top |
|
|
|
Multimedia
