Bug#852082: gwc in testing crashes at startup

[James Cowgill]

Hi,

On 23/01/17 12:39, Jaromír Mikeš wrote:
> 2017-01-22 1:11 GMT+01:00 James Cowgill <jcowgill at debian.org>:
>     On 21/01/17 14:18, Christian Grigis wrote:
>     [...]
>     > The gdb backtrace gives:
>     >
>     > (gdb) run
>     > Starting program: /home/glove/tmp/gwc-testing/gwc-0.21.19~dfsg0/gwc
>     > [Thread debugging using libthread_db enabled]
>     > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>     > Current stack limit: 8388608 bytes
>     >
>     > Program received signal SIGSEGV, Segmentation fault.
>     > 0x00007ffff6e047f9 in g_type_is_a () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
>     > (gdb) bt
>     > #0  0x00007ffff6e047f9 in g_type_is_a () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
>     > #1  0x00007ffff7519084 in gtk_type_new () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
>     > #2  0x000055555557223c in led_bar_new (segments=20, orientation=0) at gtkledbar.c:82
> 
>     The problem is here. led_bar_get_type returns an unsigned int, but
>     gtk_type_new expects a "GtkType" which is an integer with the same size
>     as a pointer. This code is going to need porting to work on 64-bit
>     arches.
> 
> James I guess as it wouldn't be trivial to fix it by patch and we need
> to this issue must be fixed upstream.
> Am I right?

It's definitely an upstream issue, but I fear that by just pushing it
upstream the package will be kicked out of stretch. It's hard to say how
much work it would be until someone tries to fix it - it could be just
this one function that's broken, or it could be many. You can probably
catch a lot of these by enabling -Wconversion.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170123/5599fead/attachment.sig>