From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 920 invoked from network); 26 Feb 2022 02:46:25 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Feb 2022 02:46:25 -0000 Received: (qmail 1931 invoked by uid 550); 26 Feb 2022 02:46:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1893 invoked from network); 26 Feb 2022 02:46:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S7wdoXYdNqb7/yzzRaaxp2lvLeevs2uAdxzD8+pDtRg=; b=l2b8koPLZa7fPUQK29t/IA++iU+dR7LwmNRGc8059DVn1DebtpkRIDSg7mTm3rMXKy yfSIIGv5NCWhB3JKMttAlw4WhQeFU54jYY7KD1dYhsIGjPJC5nGnTFc+l/XkyqDjgCXz qgp95lXx5+ykeSESIRTjcT4bmYwsAbxkVg8NLAwNghAjeKqvm3Qjh7IT+JgZEgOOoAjw yAq7XGufCmPuldBRDHoLJMaqV91JgfYeATAhb4vcsUzGbnYvS4rR1aYR4VtgeWNb88Lx p11A/9TiPFBXmkfmkBDzr2UUaDe9Hbt/xCnE68Nmngw8P02nxfSSsQ0P4oLhC2hQ/c60 3KCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S7wdoXYdNqb7/yzzRaaxp2lvLeevs2uAdxzD8+pDtRg=; b=r3sN5LFBtHdEDlh2WnPBptQpZTP0lTambuc070Z4ptnJ8FpzSf7MW2tgAvz33mSeRn 16J/7pXMbIaarObF1EV/W3FcE3z0j3BeURWefbiRwWMkalJ02zBHyhSfwK7Jg3GcJTNg kpzQuUUFbGL7uADbzM9hrtZuflhfgg2vgueCDMoLNQOhYwp+WrDOCERpVg2Lr10NsbA2 9T9d2znuZGbuj3QeUzOtCKEPrajzxDxBjMuUC5qoNfnK5ihYrGbm+bxQmuuh75nvJXzA A8c9oV6xscPCghv3jx3nNwIoGrhy1Yd8ZZUrgKxK1tfd0MGawDSDeTc04aVhmSSY5uyD hu5w== X-Gm-Message-State: AOAM533X8VECh0gvQbey/hFzOBKmTHvK0DuGxS69a01dyZ5iUl14eFWE Rf9nQxUaPFsFSuMyPOdbS1ERn/LH9z7KnIQ4U4tMApG1 X-Google-Smtp-Source: ABdhPJyd25vj1K7YLj+FxxM/i4PR8menrmH6VMbEDFqH71GpB/GjPfCH+/+yamST/9J4QrdVr7CSUEzvQq8LbQgUF40= X-Received: by 2002:a17:906:4cca:b0:6ce:6a06:bf7 with SMTP id q10-20020a1709064cca00b006ce6a060bf7mr8491821ejt.109.1645843571212; Fri, 25 Feb 2022 18:46:11 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20220225233234.GA7074@brightrain.aerifal.cx> References: <20220225233234.GA7074@brightrain.aerifal.cx> From: naruto canada Date: Sat, 26 Feb 2022 02:46:10 +0000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Re: anyone know how to approach this problem (expect5.x.x hangs) On 2/25/22, Rich Felker wrote: > On Fri, Feb 25, 2022 at 07:35:39PM +0000, naruto canada wrote: >> On 2/25/22, naruto canada wrote: >> > hi >> > >> > I'm in the process of porting all my desktop env. over to musl. >> > I'm about 70% done. I hit a few minor snags but got over them. >> > I had expected a lot more painful experience, but it turned out ok. >> > I could not get xserver to compile but will work around using vnc for >> > now. >> > I am quite happy I got qemu to compile. >> > The last 30% (Browsers !!!), I dare not approach them right now. >> > >> > Anyway, back to my probem, expect5.x.x hangs, >> > no seg fault, so I do not know how to approach this problem. >> > normally I do a simple test: >> > expect -c "spawn ls" # this always succeeds. >> > >> > (I use expect to automate password creation) >> > VNCRP=123456 # need 6 characters # create ~/.vnc/passwd >> > echo '#!/usr/bin/expect >> > set timeout -1 >> > spawn vncpasswd >> > expect "Password:" >> > send "'$VNCRP'\r" >> > expect "Verify:" >> > send "'$VNCRP'\r" >> > expect "Would you like to enter a view-only password (y/n)?" >> > send "n\r" >> > interact' > /tmp/p.ex >> > expect /tmp/p.ex >> > This script works fine under glibc, but hangs under musl. >> > >> > I've already tried the same version of expect and patches from >> > aports-3.15.0/main/expect/*.patch >> > I got the same result. (it hangs) >> > >> > This is not a priority problem for me. I can easily work around it >> > without using expect. >> > Just wondering if anyone know how to approach this problem (when there >> > is no seg fault) >> >> I did a quick strace, and compare it with glibc: >> GLIBC CASE: >> .... >> open("/tmp/p.ex", O_RDONLY) = 4 >> spawn vncpasswd >> open("/dev/ptmx", O_RDWR) = 4 >> open("/etc/group", O_RDONLY|O_CLOEXEC) = 5 >> open("/dev/pts/18", O_RDWR|O_NOCTTY) = 5 >> Password: >> Verify: >> Would you like to enter a view-only password (y/n)? n >> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=956, >> si_status=0, si_utime=0, si_stime=0} --- >> >> open("/dev/null", O_RDONLY) >> = 4 >> open("/dev/null", O_RDONLY) = 3 >> open("/dev/null", O_RDONLY) = 2 >> open("/dev/null", O_RDONLY) = 0 >> +++ exited with 0 +++ >> >> MUSL CASE: >> open("/tmp/p.ex", O_RDONLY|O_LARGEFILE) = 7 >> spawn vncpasswd >> open("/dev/ptmx", O_RDWR|O_NOCTTY|O_LARGEFILE) = 7 >> open("/dev/pts/3", O_RDWR|O_NOCTTY|O_LARGEFILE) = 8 >> syscall_397(0xffffff9c, 0xb6f624e0, 0, 0x7ff, 0xbe927e48, 0xb6f624e0) >> = -1 (errno 38) >> syscall_397(0x8, 0xb6f58350, 0x1000, 0x7ff, 0xbe927e48, 0xb6f624e0) = >> -1 (errno 38) >> syscall_403(0, 0xbe928258, 0xb6e82de0, 0, 0xbe928334, 0) = -1 (errno 38) >> syscall_389(0x10, 0, 0, 0xb6f62170, 0xbe92815c, 0xbe92808c) = -1 (errno >> 38) >> >> It seems to block or stopped at syscall_389 >> ( arch/arm/bits/syscall.h.in:#define __NR_membarrier 389 ) > > The syscall has returned, so it's something after that which is > hanging. Running under gdb and hitting ^C could show where. > > Something very wrong is going on here, since the syscalls are failing > with ENOSYS but no fallback path has been taken. If it's musl making > them, it will not assume these exist but will check for ENOSYS and > make an alternate syscall if that happens. So it would seem that > either these syscalls are being made directly by the application > (expect) or something went very wrong in building musl (weird patches? > stale build dir previously used for another arch? ..?) that has the > wrong thing happening. > > What kernel version are you using? There was a recent thread on the > list where someone had a badly patched kernel from Google that did > something to mess up ENOSYS, and strace hid the bug, so perhaps this > is similar. It is compiled on (and running on) android phone. I have no control over the kernel (3.4.0-perf-g63c3cac) (LG G3). (I have already matched kernel header (3.4.0) when compile the tool and the World) I used 3.10.x before and got into problem, so I matched the kernel header this time. This is the gdb result (I ran 3 times). It always stopped at the same place: gdb expect GNU gdb (GDB) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-00200-linux-musleabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from expect...done. (gdb) run /tmp/p.ex Starting program: /00200/bin/expect /tmp/p.ex spawn vncpasswd ^C Program received signal SIGINT, Interrupt. __cp_begin () at src/thread/arm/syscall_cp.s:23 23 src/thread/arm/syscall_cp.s: No such file or directory. (gdb) BTW. gcc is version 5.3.0 and the patch set is exactly as from: https://github.com/GregorR/musl-gcc-patches musl-1.2.2 is not patched. specs file is patched to always emit: -march=armv4 -mtune=strongarm -mno-thumb-interwork -mfloat-abi=hard Strange, "svc 0" should not have stopped or blocked, because normally kernel should have returned right away. svc 0 <=== line 23 __cp_end: ldmfd sp!,{r4,r5,r6,r7} bx lr I will try the exact same build script later on x86 and see.what happens. I will report back later. > > Rich > > >