+1 maintenance report

[Christian Ehrhardt]

On Mon, Jan 11, 2021 at 4:53 PM Steve Langasek
<steve.langasek at ubuntu.com> wrote:
>
> +1 maintenance shift Thursday and Friday, 7-8 Jan 2021.
>
> I took a look at the libjsoncpp transition.
>
>  - opendht failed to build, but builds fine in sid and also built fine in a
>    hirsute chroot, so I've given the build back on all archs and it's
>    built/building successfully now.
>  - scanning update_excuses for other packages linked to libjsoncpp, I
>    spotted that waybar depends on both libjsoncpp and on spdlog, which was
>    not a candidate because it was dep-wait on i386.  I fixed up the i386
>    whitelist to include liblist-more-utils-xs-perl, which has now built, so
>    in theory this will unblock soon.
>  - also linked to digikam via opencv; digikam has a new build-dependency on
>    qtwebengine5-dev, which is only available on x86 / arm, so I removed the
>    ppc64el/s390x/riscv64 binaries from the release pocket to let this
>    migrate.
>  - and to gst-plugins-bad1.0 via opencv, which seems to have a build failure
>    on ppc64el and s390x due to a segfault in gst-plugin-scanner and in
>    gst-codec-info-1.0; reproducible on s390x in a built tree with
>    `/usr/lib/s390x-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-codec-info-1.0
>     debian/gstreamer1.0-plugins-bad/usr/lib/s390x-linux-gnu/gstreamer-1.0/libgstlv2.so`
>    but haven't had time yet to diagnose and resolve.  A backtrace is:

Hi Steve,
I started to look into that as well today and got as far as you did
(identifying libgstlv2.so).
I also pinged ubuntu-desktop and it didn't ring any bell being a known
issue there.
The failing bits of  gst-plugins-bad1.0 are the same that worked a few
weeks before,
so I started trying to identify the component that brought the change
- with suspects like
libgstreamer1.0-0 1.18.2-1build1 -> libgstreamer1.0-0 1.18.0-3.
I'm still on +1, so I'll continue on that tomorrow.

> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000004ee6 in ?? ()
> (gdb) bt
> #0  0x0000000000004ee6 in ?? ()
> #1  0x000003fffdf8527e in plugin_cleanup (plugin=<optimized out>)
>     at ../ext/lv2/gstlv2.c:381
> (gdb)

Might I ask how you've got to plugin_cleanup - in my case it looks
like the following stack.
(Which seems to indicate memory is clobbered as the main function
fully completes and then on return hell breaks loose)

(gdb) bt
#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x000003fffd9aaa88 in __GI_abort () at abort.c:79
#2  0x000003fffd9c1896 in __assert_fail_base
    (fmt=<optimized out>, assertion=assertion at entry=0x3fffd00a382
"frame->node", file=file at entry=0x3fffd00a1c8 "../src/zix/btree.c",
line=line at entry=716, function=function at entry=0x3fffd00a7f0
"zix_btree_get") at assert.c:92
#3  0x000003fffd9c190e in __GI___assert_fail (assertion=0x3fffd00a382
"frame->node", file=0x3fffd00a1c8 "../src/zix/btree.c",
line=<optimized out>, function=0x3fffd00a7f0 "zix_btree_get")
    at assert.c:101
#4  0x000003fffd005148 in sord_free () at /lib/s390x-linux-gnu/libsord-0.so.0
#5  0x000003fffd292168 in lilv_world_free () at
/lib/s390x-linux-gnu/liblilv-0.so.0
#6  0x000003fffdf9363e in  () at /lib/ld64.so.1
#7  0x000003fffd9ce256 in __run_exit_handlers (status=<optimized out>,
listp=0x3fffdb4d540 <__exit_funcs>,
run_list_atexit=run_list_atexit at entry=true,
run_dtors=run_dtors at entry=true)
    at exit.c:108
#8  0x000003fffd9ce3f0 in __GI_exit (status=<optimized out>) at exit.c:139
#9  0x000003fffd9aadd4 in __libc_start_main (main=
    0x2aa00001d20 <main>, argc=<optimized out>, argv=0x3fffffff328,
init=<optimized out>, fini=<optimized out>, rtld_fini=0x3fffdf93410,
stack_end=0x3fffffff270) at libc-start.c:348
#10 0x000002aa00002aa4 in _start ()



> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                   https://www.debian.org/
> slangasek at ubuntu.com                                     vorlon at debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd