Bug 52446 - Kino segfaults on startup with both gcc 3.3.3-r5 and 3.4.0-r4
|
Bug#:
52446
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: AMD64
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: amd64@gentoo.org
|
Reported By: sr@sander.yi.org
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: Kino segfaults on startup with both gcc 3.3.3-r5 and 3.4.0-r4
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2004-05-30 05:56 0000
|
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
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. ***
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).
