Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
kino segfaults on startup. It doesn't seem to matter whether it is compiled with 3.3.3-r5 or 3.4.0-r4. According to the strace output the same problem occurs Reproducible: Always Steps to Reproduce: 1. 2. 3. emerge -pv kino: [ebuild R ] media-video/kino-0.7.1 -quicktime 0 kB last few lines of strace kino: lseek(15, 0, SEEK_SET) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 read(15, "\377\330\377\340\0\20JFIF\0\1\1\1\0H\0H\0\0\377\376\0\27"..., 65536) = 5132 read(15, "", 57344) = 0 brk(0) = 0x552b399000 brk(0x552b3c3000) = 0x552b3c3000 close(15) = 0 munmap(0x2a9a5b6000, 4096) = 0 write(2, "> Kino Common being built", 25> Kino Common being built) = 25 write(2, "\n", 1 ) = 1 write(2, "> Creating page editor", 22> Creating page editor) = 22 write(2, "\n", 1 ) = 1 --- SIGSEGV (Segmentation fault) @ 0 (0) --- write(3, "\233\21\3\0\3\0\240\1H\0\0\0\233\24\25\0\3\0\240\1\1\0"..., 4756) = 47 56 write(3, " \21\2\0\0\0\0\0", 8) = 8 write(3, "+\21\1\0", 4) = 4 read(3, "\1\1\210\0\0\0\0\0\3\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0X\v\326"..., 32) = 32 fork() = 20208 wait4(20208, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 20208 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigreturn(0x552b03e950) = 20208 _exit(1) = ?
Interesting... I managed to create a patch that comes around the SIGSEGV. They are caused my bad coding: GDKImage{Filters,Transitions}Repository doesnt set its member "selected_{filter,transition}" to NULL. I will attach a patch for this. On the other side, after eliminating this SIGSEGVs, a SIG32 emerge and its backtrace looks very much like the backtrace of the nautilus/gftp SIG32. Program received signal SIG32, Real-time event 32. 0x0000002a95eb6dfe in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) bt #0 0x0000002a95eb6dfe in pthread_getconcurrency () from /lib/libpthread.so.0 #1 0x0000002a95eb6c80 in pthread_getconcurrency () from /lib/libpthread.so.0 #2 0x0000002a95eb65b7 in pthread_create () from /lib/libpthread.so.0 #3 0x00000000004b579f in Storyboard::redraw() (this=0xfdcd80) at storyboard.cc:742 #4 0x0000000000480cbd in PageEditor::ResetBar() (this=0xce27f0) at page_editor.cc:1334 #5 0x0000000000480be8 in PageEditor::DrawBar(int) (this=0xce27f0, currentFrame=-1) at page_editor.cc:1308 #6 0x000000000047e62a in PageEditor::showFrame(int, int) (this=0xce27f0, i=-1, no_audio=1) at page_editor.cc:288 #7 0x000000000047adcf in KinoCommon::moveToFrame(int) (this=0xce0340, frame=-1) at kino_common.cc:1183 #8 0x00000000004785e7 in KinoCommon::setCurrentPage(int) (this=0xce0340, page=0) at kino_common.cc:405 #9 0x0000002a967f1381 in _gtk_marshal_VOID__POINTER_UINT (closure=0xcdad00, return_value=0x8, n_param_values=2147483647, param_values=0x7fbfffee20, invocation_hint=0xfea020, marshal_data=0x0) at gtkmarshalers.c:2075 #10 0x0000002a9786975f in g_closure_invoke (closure=0xcdad00, return_value=0x0, n_param_values=3, param_values=0x7fbfffee20, invocation_hint=0x7fbfffece0) at gclosure.c:437 #11 0x0000002a9787b43e in signal_emit_unlocked_R (node=0xa17770, detail=0, instance=0xc3acb0, emission_return=0x0, instance_and_params=0x7fbfffee20) at gsignal.c:2436 #12 0x0000002a9787a34e in g_signal_emit_valist (instance=0xc3acb0, signal_id=3221220896, detail=0, var_args=0x7fbfffefe0) at gsignal.c:2195 #13 0x0000002a9787a6a3 in g_signal_emit (instance=0x7fbfffe970, signal_id=8, detail=2147483647) at gsignal.c:2239 #14 0x0000002a968041ae in gtk_notebook_switch_page (notebook=0xc3acb0, page=0xc476a0, page_num=0) at gtknotebook.c:3866 #15 0x0000000000430e32 in main (argc=1, argv=0x7fbffff188) at main.c:159
Created an attachment (id=32337) [details] Preliminary patch to allow to get the nautilus like SIG32 instead SIGSEGVs for bad kino source code
seems that people are getting this same crash on x86 - see bug #50572 here's another backtrace if it's any help: #0 0x00000000004a58e9 in GDKImageTransitionRepository::SelectionChange() ( this=0xd00238) at image_transitions.cc:505 #1 0x00000000004a59ec in GDKImageTransitionRepository::Initialise(_GtkOptionMenu*, _GtkBin*) (this=0xd00238, menu=0xb10510, container=0x0) at image_transitions.cc:488 #2 0x0000000000494ad1 in PageMagick (this=0xcfd9b0, common=0x98a970) at page_magick.cc:1365 #3 0x000000000046d9f3 in KinoCommon (this=0xcf4220, widget=0xc1ae00) at kino_common.cc:103 #4 0x0000000000496643 in kinoInitialise (widget=0xc1ae00) at commands.cc:148 #5 0x000000000042f6af in main (argc=1, argv=0x7fbffff128) at main.c:157
Herbie, did you use my patch ?
No, that was without your patch. Just re-emerged kino and it now seems to be working. I got no sigsegv or sig32's and it ran perfectly. Not too sure what I've changed on my system that could have affected this. I'm using gcc-3.4 btw.
I still get those SIG32s. I will mail the kino developers about it.
As the kino developer, I just want to confirm that there is a known bug in Kino 0.7.1, which Danny's patch addresses. We have had the fix in our CVS for some time, but it is a little different: I use a member initializer in the constructor: GDKImageTransitionRepository::GDKImageTransitionRepository() : selected_transition( 0 ) and GDKImageFilterRepository::GDKImageFilterRepository() : selected_filter( 0 ) I am working on a 0.7.2 release, so I am trying to reproduce the bug on his machine. So far, with the slowness of ssh X11 forwarding over the net, it is not reproducing.
Ok, those SIG32s only get thrown when you run kino via gdb. Seems to be a bug in gdb that is already being workd on. Patch is in CVS by now.
*** Bug 50572 has been marked as a duplicate of this bug. ***
Please reopen this bug. This was never fixed in kino-0.7.1. People are still complaining about segfaults at start on amd64. See: http://forums.gentoo.org/viewtopic.php?p=1903538#1903538 and: http://forums.gentoo.org/viewtopic.php?t=252484&highlight=kino+amd64 Requesting masking kino-0.7.1 as -amd64 and promoting kino-0.7.5 as + in its place.
reopened per user request
0.7.5 marked stable in cvs as most of the forum ppl report success - I use it just fine (now libdv is fixed).
