mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: naruto canada <narutocanada@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Re: anyone know how to approach this problem (expect5.x.x hangs)
Date: Sat, 26 Feb 2022 08:48:01 -0500	[thread overview]
Message-ID: <20220226134800.GB7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAKrOiPQOe38UrWTP+yV+8VtdLg07V9TEot9mPNew08CMDnr62Q@mail.gmail.com>

On Sat, Feb 26, 2022 at 02:46:10AM +0000, naruto canada wrote:
> On 2/25/22, Rich Felker <dalias@libc.org> wrote:
> > On Fri, Feb 25, 2022 at 07:35:39PM +0000, naruto canada wrote:
> >> On 2/25/22, naruto canada <narutocanada@gmail.com> 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:

The kernel headers you use should not matter at all. Do you know where
we can find the sources for LG's kernel? I'm guessing they did
something horrible...

Rich

  reply	other threads:[~2022-02-26 13:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 17:59 [musl] " naruto canada
2022-02-25 19:35 ` [musl] " naruto canada
2022-02-25 23:32   ` Rich Felker
2022-02-26  2:46     ` naruto canada
2022-02-26 13:48       ` Rich Felker [this message]
2022-02-27 15:35         ` naruto canada
2022-02-27 21:29           ` naruto canada
2022-02-28  0:16             ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220226134800.GB7074@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=narutocanada@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).