NetBSD Problem Report #55899

From mlelstv@hoppa.1st.de  Thu Dec 31 08:24:37 2020
Return-Path: <mlelstv@hoppa.1st.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 95E091A921F
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 31 Dec 2020 08:24:37 +0000 (UTC)
Message-Id: <20201231082349.AAD07E@hoppa.1st.de>
Date: Thu, 31 Dec 2020 09:23:49 +0100 (CET)
From: mlelstv@serpens.de
Reply-To: mlelstv@serpens.de
To: gnats-bugs@NetBSD.org
Subject: graphics/cheese build locks up by gst-inspect
X-Send-Pr-Version: 3.95

>Number:         55899
>Category:       pkg
>Synopsis:       graphics/cheese build locks up by gst-inspect
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 31 08:25:00 +0000 2020
>Last-Modified:  Wed Mar 10 08:40:01 +0000 2021
>Originator:     Michael van Elst
>Release:        NetBSD 9.0_STABLE
>Organization:

>Environment:


System: NetBSD victory.netbsd.org 9.0_STABLE NetBSD 9.0_STABLE (GENERIC64) #5: Tue Oct 6 21:07:14 CEST 2020 mlelstv@gossam:/home/netbsd9/obj.evbarm64-el/home/netbsd9/src/sys/arch/evbarm/compile/GENERIC64 evbarm
Architecture: aarch64
Machine: evbarm
>Description:
Building graphics/cheese starts gst-inspect from gstreamer which gets
stuck in an infinite loop when running in a earmv7hf chroot.

The infinite loop is a gstreamer bug (in gst/gstpluginloader.c function
read_one) which fails to handle a simple EOF from the plugin scanner process.

The reason for the plugin scanner to return EOF (and exit) is unknown,
so fixing the gstreamer bug might not be sufficient. But it might be
triggered by a plugin that is broken for earmv7hf as the same build
succeeds when done natively for aarch64.

>How-To-Repeat:
Try to build graphics/cheese
>Fix:


>Audit-Trail:
From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/55899 graphics/cheese build locks up by gst-inspect
Date: Wed, 10 Mar 2021 09:38:32 +0100

 The gst-plugin-scann helper program crashes with a BUS error.

 8621      1 gst-plugin-scann PSIG  SIGBUS SIG_DFL: code=BUS_ADRALN, addr=0xf2d606a1, trap=-1845493727)
 8621      2 gst-plugin-scann RET   netbsd32____lwp_park60 -1 errno 4 Interrupted system call
 8621      1 gst-plugin-scann NAMI  "gst-plugin-scann.core"


 You can repeat that outside of the cheese build by running
 gst-inspect-1.0 when the gnome-video-effects packages is also
 installed.

 Here is a stack trace extracted from the coredump:

 (gdb) where
 #0  0x6f6a1610 in f0r_get_param_value ()
    from /usr/pkg/lib/frei0r-1/lightgraffiti.so
 #1  0x795936b0 in gst_frei0r_klass_install_properties ()
    from /usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so
 #2  0x79594a30 in gst_frei0r_filter_class_init ()
    from /usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so
 #3  0x7bce6e58 in g_type_class_ref () from /usr/pkg/lib/libgobject-2.0.so.0
 #4  0x7bdbd428 in gst_element_register (plugin=0x7a52a178, 
     name=0x7a5273c0 "frei0r-filter-light-graffiti", rank=0, type=2060416288)
     at gstelementfactory.c:240
 #5  0x79594d94 in gst_frei0r_filter_register ()
    from /usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so
 #6  0x79593124 in register_plugins ()
    from /usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so
 #7  0x79593410 in plugin_init ()
    from /usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so
 #8  0x7bdecdb0 in gst_plugin_register_func (plugin=0x7a52a178, 
     desc=0x795a93a0 <gst_plugin_desc>, user_data=0x0) at gstplugin.c:525
 #9  0x7bdef32c in _priv_gst_plugin_load_file_for_registry (
     filename=filename@entry=0x7b81c60c "/usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so", registry=0x7bd1f860, registry@entry=0x0, error=error@entry=0x0)
     at gstplugin.c:886
 #10 0x7bdeffe0 in gst_plugin_load_file (
     filename=filename@entry=0x7b81c60c "/usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so", error=error@entry=0x0) at gstplugin.c:682
 #11 0x7bdf2de4 in do_plugin_load (tag=89, 
     filename=0x7b81c60c "/usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so", 
     l=<optimized out>) at gstpluginloader.c:728
 #12 handle_rx_packet (payload_len=<optimized out>, 
     payload=0x7b81c60c "/usr/pkg/lib/gstreamer-1.0/libgstfrei0r.so", tag=89, 
     pack_type=<optimized out>, l=<optimized out>) at gstpluginloader.c:836
 #13 read_one (l=0x7bb4d1c8) at gstpluginloader.c:1006
 #14 exchange_packets (l=l@entry=0x7bb4d1c8) at gstpluginloader.c:1034
 #15 0x7bdf3e80 in _gst_plugin_loader_client_run () at gstpluginloader.c:583


 Removing lightgraffiti.so avoids the crash.

    0x6f6a15bc <f0r_get_param_value>:        ldr     r3, [pc, #172]  ; 0x6f6a1670 <f0r_get_param_value+180>
    0x6f6a15c0 <f0r_get_param_value+4>:      add     r12, r2, r2, lsl #1
    0x6f6a15c4 <f0r_get_param_value+8>:      add     r3, pc, r3
    0x6f6a15c8 <f0r_get_param_value+12>:     ldr     r3, [r3, #88]   ; 0x58
    0x6f6a15cc <f0r_get_param_value+16>:     add     r12, r2, r12, lsl #2
    0x6f6a15d0 <f0r_get_param_value+20>:     add     r3, r3, r12, lsl #2
    0x6f6a15d4 <f0r_get_param_value+24>:     ldr     r0, [r0, #16]
    0x6f6a15d8 <f0r_get_param_value+28>:     ldr     r3, [r3, #48]   ; 0x30
    0x6f6a15dc <f0r_get_param_value+32>:     ldr     r2, [r0, r2, lsl #2]
    0x6f6a15e0 <f0r_get_param_value+36>:     mov     r12, r1
    0x6f6a15e4 <f0r_get_param_value+40>:     cmp     r3, #4
    0x6f6a15e8 <f0r_get_param_value+44>:     addls   pc, pc, r3, lsl #2
    0x6f6a15ec <f0r_get_param_value+48>:     b       0x6f6a160c <f0r_get_param_value+80>
    0x6f6a15f0 <f0r_get_param_value+52>:     b       0x6f6a1610 <f0r_get_param_value+84>
    0x6f6a15f4 <f0r_get_param_value+56>:     b       0x6f6a1634 <f0r_get_param_value+120>
    0x6f6a15f8 <f0r_get_param_value+60>:     b       0x6f6a1640 <f0r_get_param_value+132>
    0x6f6a15fc <f0r_get_param_value+64>:     b       0x6f6a164c <f0r_get_param_value+144>
    0x6f6a1600 <f0r_get_param_value+68>:     b       0x6f6a1604 <f0r_get_param_value+72>
    0x6f6a1604 <f0r_get_param_value+72>:     ldr     r3, [r2]
    0x6f6a1608 <f0r_get_param_value+76>:     str     r3, [r1]
    0x6f6a160c <f0r_get_param_value+80>:     bx      lr
 => 0x6f6a1610 <f0r_get_param_value+84>:     vldr    d6, [r2]
    0x6f6a1614 <f0r_get_param_value+88>:     vldr    d7, [pc, #60]   ; 0x6f6a1658 <f0r_get_param_value+156>
    0x6f6a1618 <f0r_get_param_value+92>:     vcmpe.f64       d6, d7
    0x6f6a161c <f0r_get_param_value+96>:     vldr    d7, [pc, #60]   ; 0x6f6a1660 <f0r_get_param_value+164>
    0x6f6a1620 <f0r_get_param_value+100>:    vmrs    APSR_nzcv, fpscr
    0x6f6a1624 <f0r_get_param_value+104>:    vldr    d6, [pc, #60]   ; 0x6f6a1668 <f0r_get_param_value+172>
    0x6f6a1628 <f0r_get_param_value+108>:    vmovle.f64      d7, d6
    0x6f6a162c <f0r_get_param_value+112>:    vstr    d7, [r1]
    0x6f6a1630 <f0r_get_param_value+116>:    bx      lr


 The branch table at 0x6f6a15ec is a switch statement with entries for:

 default:
 F0R_PARAM_BOOL       0
 F0R_PARAM_DOUBLE     1
 F0R_PARAM_COLOR      2
 F0R_PARAM_POSITION   3
 F0R_PARAM_STRING     4

 and the parameter type in r3 is 0. A stray value in r6 points to
 the bool p_statsDifference which happens to be add an odd address.

 The code for FOR_PARAM_BOOL however tries to access the parameter with
 a vldr instruction which traps.


 Reason is that the code treats FOR_PARAM_BOOL as double:

 In frei0r.h:

 typedef double f0r_param_bool;

 In frei0r.hpp:

         case F0R_PARAM_BOOL :
           *static_cast<f0r_param_bool*>(param)
             = *static_cast<f0r_param_bool*>(ptr) > 0.5 ? 1.0 : 0.0;


 But the register_param function does not. A C++ type bool is registered
 as FOR_PARAM_BOOL and later accessed as a double.

     void register_param(bool& p_loc,
                         const std::string& name,
                         const std::string& desc)
     {     
       param_ptrs.push_back(&p_loc);
       s_params.push_back(param_info(name,desc,F0R_PARAM_BOOL));
     }       




 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

>Unformatted:

Home	PR Database Search