[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150921075719.GV12087@example.net>
Date: Mon, 21 Sep 2015 09:57:19 +0200
From: u-wsnj@...ey.se
To: musl@...ts.openwall.com
Subject: Re: pthread_getattr_np() vs explicit runtime loader
On Sun, Sep 20, 2015 at 03:41:32PM -0400, Rich Felker wrote:
> > These _are_ several of the binaries of gcc-5.x which crash. It looks like
> > the ones which crash (java-related ones?) are using pthread_getattr_np()
> > while others do not. I did not though consequently check all of them.
> >
> > You can easily test this if you have got say a jv-convert binary of
> > gcc-5.2.0, dynamically linked with musl and run this binary via the
> > explicit loader. Yours and mine environments are different but I would
> > not be surprised if the binary crashes for you too.
>
> I might get a chance to look later, but first thought: is jv-convert
Unfortunately I could not get any useful backtrace from gdb, this
would need more time.
Hope you would make a simple crash test with
/<path-to-musl>/libc.so /<path-to>/jv-convert.
> using boehm gc? I ask because boehm is one of the main users (iirc) of
Libjava (and then presumably jv-convert too) involves boehm gc.
> pthread_getattr_np and it's full of UB. It's possible that gcc 5 broke
> some of the things it's doing, or that they were already broken but
> didn't happen to crash before. I think boehm needs some patches to
> work safely on musl but maybe not anymore.
boehm needs some patches to be buildable but this is about removing
harmful glibc-related include/define heuristics.
For the record, there are no similar crashes of jv-convert or other
binaries from an older gcc (4.2.3) built with the same musl.
Rune
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
