[uclibc-ng-devel] uclibc-ng 1.0.18 - libc.a binaries freeze

[Lance Fredrickson]

Using uclibc-ng 1.0.18, binaries linked against dynamic libc.so seems to 
work just fine.  Binaries created completely statically are 
non-responsive, and freeze up on the console.  A few binaries I've tried 
are openvpn, tinc, transmission-daemon.  I have to send SIGKILL to 
terminate the process.  A simple hello world did compile and run fine 
though, so possibly having to do with additional functionality placed 
into libc.a.


Here's a strace of one binary if that offers any insight.

root@R7000:~/src/tinc-1.1pre14/src# strace ./tinc --version
execve("./tinc", ["./tinc", "--version"], [/* 24 vars */]) = 0
brk(NULL)   = 0x1ef000
brk(0x1efcb4)   = 0x1efcb4
set_tls(0x1ef490, 0x1c4220, 0x1e9418, 0x1e8bd8, 0x4) = 0
set_tid_address(0x1ef068)   = 9961
set_robust_list(0x1ef070, 12)   = -1 ENOSYS (Function not 
implemented)
rt_sigaction(SIGRTMIN, {0x165014, [], SA_RESTORER|SA_SIGINFO, 0x14f058}, 
NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x164ea0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 
0x14f058}, NULL, 8) = 0

rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
open("/dev/urandom", O_RDONLY)  = 3
read(3, "\\\177t)", 4)  = 4
close(3)= 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE SEGV RTMIN RT_1], [], 8) = 0
rt_sigaction(SIGILL, {0x98734, ~[ILL TRAP BUS FPE SEGV RTMIN RT_1], 
SA_RESTORER, 0x14f04c}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, ~[ILL TRAP BUS FPE KILL SEGV STOP RTMIN 
RT_1], 8) = 0

--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x98800} ---
futex(0x1e5df0, FUTEX_WAIT_PRIVATE, 2, NULL


thanks,
Lance
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] [RFC PATCH v2 0/1] libpthread/nptl: Use arch-dependent unwind-forcedunwind.c if available

[Ignacy Gawędzki]

On Tue, Oct 04, 2016 at 06:46:22AM +0200, thus spake Waldemar Brodkorb:
> Hi Ignacy,
> Ignacy Gawędzki wrote,
> 
> > On Mon, Oct 03, 2016 at 06:13:45PM +0200, thus spake Waldemar Brodkorb:
> > > Hi Ignacy,
> > > Ignacy Gawędzki wrote,
> > > 
> > > > On Mon, Oct 03, 2016 at 12:26:19PM +0200, thus spake Ignacy Gawedzki:
> > > > > On Sat, Oct 01, 2016 at 01:22:37PM +0200, thus spake Waldemar 
> > > > > Brodkorb:
> > > > > > Can you please try with 1.0.18? I can not reproduce the issue with
> > > > > > 1.0.18.
> > > > > > 
> > > > > > I just get "caught" with the test app.
> > > > > > 
> > > > > > May be it was accidentally fixed in the release.
> > > > > 
> > > > > I don't get the uncaught exception with 1.0.18 indeed.  This is
> > > > > certainly due to the way libpthread is now integrated into libc.  Now
> > > > > the version of Unwind_Resume that is called is always the one from
> > > > > libgcc_1.so, even when using threads.  I'm affraid that this is not
> > > > > the right thing to do, because the wrapping code for Unwind_Resume in
> > > > > libpthread was there for some reason.
> > > > 
> > > > Okay, I've explored that problem a bit more today and I have
> > > > additional information.  It seems that the Unwind_* functions are
> > > > provided in the libc for local use and are not supposed to be visible
> > > > for the dynamic linker.  Compare that with GNU libc where the Unwind_*
> > > > symbols are local.
> > > > 
> > > > Right now it also seems that none of uClibc's code actually uses these
> > > > functions, at least in my case, so the incorrect Unwind_Resume inside
> > > > uClibc is harmless.
> > > 
> > > But isn't pthread_cancel using pthread_cancel_init from
> > > libpthread/nptl/sysdeps/pthread/unwind-forcedunwind.c?
> > 
> > Yes, it looks like it does.  But at least _Unwind_Resume doesn't seem
> > to be used at all.
> > 
> > > > The problem I was having with v1.0.17 was that by linking with
> > > > libpthread, the Unwind_Resume wrapper code in that library was
> > > > overriding the implementation in libgcc_s that was supposed to be
> > > > called directly.
> > > 
> > > I still do not understand the issue.
> > > As far as I know, the Unwind* functions in uClibc and GNU libc is
> > > wrapper code around gcc libgcc_s.so.1 which is loaded via dlopen
> > > at runtime.
> > 
> > Yes, they are, but the problem is with the way the ARM unwinder works.
> > Obviously, it doesn't expect to have one additional frame added by a
> > call to _Unwind_Resume.  This is why in the case of the ARM
> > architecture, a specially-crafted version of the wrapper around
> > _Unwind_Resume is provided which doesn't create a new frame.
> > 
> > > I once asked about this on the libc mailinglist:
> > > https://sourceware.org/ml/libc-help/2014-07/msg0.html
> > >  
> > > > Now that libpthread (and librt for that matter) are integrated into
> > > > libc, it seems the problem is gone, because the libgcc_s
> > > > implementation is not overridden by uClibc's.  But this happens only
> > > > because libgcc_s.so is listed before libc.so in the .dynamic section,
> > > > and if it were not the case anymore, for any reason, the problem would
> > > > reemerge immediately.
> > > > 
> > > > You can force the problem to re-emerge by simply preloading libc.so
> > > > using LD_PRELOAD.  This makes uClibc's incorrect implementation of
> > > > Unwind_Resume to be called and the execution of the example code
> > > > aborts instead of outputting "caught".
> > > > 
> > > > Please find attached the updated patch for v1.0.18.  This is more like
> > > > a quick fix, since a proper fix would most probably be to make those
> > > > conflicting symbols local in the resulting .so.
> > > 
> > > But what exactly is fixed by the patch then?
> > 
> > The patch makes _Unwind_Resume in libpthread/nptl/ be implemented by
> > sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c in the case of ARM
> > and by sysdeps/pthread/unwind-forcedunwind.c otherwise.  So if
> > libc.so's _Unwind_Resume ever takes over libgcc_s.so's, or if the
> > wrapper around _Unwind_Resume is used in the future, it will simply
> > work transparently.
> > 
> > The way this is achieved is inspired by how it's already done for
> > librt with unwind-resume.c (see sysdeps/pthread/rt-unwind-resume.c).
> > 
> > > Is it still a ARM specific issue?
> > 
> > Yes it is.
> > 
> > > Could you take a look at glibc commit:
> > > commit 46abb64d6287d09100b147d062f6810066389b7e
> > > Author: Roland McGrath 
> > > Date:   Mon Jan 5 14:01:49 2015 -0800
> > > 
> > > ARM: Consolidate with generic unwinder wrapper code
> > > 
> > > I think it would be a better solution to sync with glibc and
> > > get rid of the special ARM specific versions.
> > 
> > I you look closely at this commit, it's exactly what I'm talking
> > about: it's providing an ARM-specific implementation of _Unwind_Resume
> > in assembly.  For other architectures, the generic wrapper is used.
> > 
> > Now I agree