Your message dated Sat, 18 May 2013 17:48:14 +0200
with message-id <5197a2be.3010...@debian.org>
and subject line libcogl12: SIGSEGV in cogl_onscreen_add_frame_callback
has caused the Debian Bug report #703726,
regarding libcogl12: SIGSEGV in cogl_onscreen_add_frame_callback
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
703726: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703726
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libcogl12
Version: 1.13.4-1
Severity: critical
SIGSEGV in cogl_onscreen_add_frame_callback on many application
(gnome-shell, emerillon and maybe other where use libclutter or libcogl)
backtrace (crash point most identical to gnome-shell and emerillon)
Program received signal SIGSEGV, Segmentation fault.
0x40da546c in cogl_onscreen_add_frame_callback (onscreen=0x284ae8,
callback=0x400ba085 <frame_cb>, user_data=0x1c3490, destroy=0) at
./cogl-onscreen.c:370
370 COGL_TAILQ_INSERT_TAIL (&onscreen->frame_closures, closure,
list_node);
(gdb) bt
#0 0x40da546c in cogl_onscreen_add_frame_callback (onscreen=0x284ae8,
callback=0x400ba085 <frame_cb>, user_data=0x1c3490, destroy=0) at
./cogl-onscreen.c:370
#1 0x400ba986 in clutter_stage_cogl_realize (stage_window=<optimized
out>) at ./cogl/clutter-stage-cogl.c:163
#2 0x400b6b56 in clutter_stage_x11_realize (stage_window=0x1c3490) at
./x11/clutter-stage-x11.c:609
#3 0x4010ad7c in _clutter_stage_window_realize (window=0x1c3490) at
./clutter-stage-window.c:88
#4 0x40106c7c in clutter_stage_realize (self=0x1cbbc8) at
./clutter-stage.c:761
#5 0x40b2be98 in g_cclosure_marshal_VOID__VOIDv () from
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0
#6 0x40b29654 in ?? () from
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0
#7 0x40b29654 in ?? () from
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
-- System Information:
Debian Release: 7.0
APT prefers testing-updates
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: armhf (armv7l)
Kernel: Linux 3.0.31 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libcogl12 depends on:
ii libc6 2.17-0experimental2
pn libegl1-mesa | libegl1-x11 <none>
ii libgcc1 1:4.7.2-5
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libglib2.0-0 2.35.8-1
ii libmali400-exynos [libgles2] 0.0.1
ii libx11-6 2:1.5.0-1
ii libxcomposite1 1:0.4.3-2+b1
ii libxdamage1 1:1.1.3-2+b1
ii libxext6 2:1.3.1-2
ii libxfixes3 1:5.0-4+b1
ii libxrandr2 2:1.4.0-1
ii multiarch-support 2.13-38
Versions of packages libcogl12 recommends:
ii libcogl-common 1.13.4-1
Versions of packages libcogl12 suggests:
pn libgl1-mesa-glx <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Well, so the point is, totem or gnome-shell needs libcogl.so.9, but
other library/ies they depends on (namely package libclutter-1.0-0 (>=
1.13.10-1)) needs libcogl.so.12.
As of version 1.14.0-1 package libclutter-1.0-0 correctly breaks
libcogl9 and libcogl11. So should the package libcogl12 probably Break
libclutter-1.0-0 (< 1.14.0-1)?
No need for cogl breaking clutter when clutter breaks cogl, that's only looking
for trouble.
What could make sense is for libcogl12 to break libcogl11/libcogl9, but since in
the end all rdeps of libcogl are users of clutter, the current breaks should be
fine.
I can only think of a possible issue with the current situation but it's
unlikely to be a problem:
<pochu> I don't think the current cogl breaks are good enough
<pochu> right now it's libclutter-1.0-0 that breaks libcogl9, libcogl11
<pochu> but it should be libcogl12 that breaks libcogl9, libcogl11
<pochu> otherwise you can have old libcogl9, old libclutter-1.0-0 that links
against libcogl9
<pochu> then we upload libcogl12 to unstable, and stuff may be rebuilt and link
against new libcogl12 while libclutter-1.0-0 links against old libcogl9
<pochu> then boom
<pochu> this relies on clutter being uploaded a while after libcogl, and not
immediately after as is the plan
<pochu> so probably not a big deal
<pochu> we'll see
If in the end there are real problems, we can adjust the breaks.
Cheers,
Emilio
--- End Message ---