On Wed, Nov 13, 2019 at 02:36:56PM -0800, Khem Raj wrote:
>...
> however, there could be another problem, where libgcc_s is lazily
> loaded during pthread_exit and
> application is not using root user which many daemons do where they
> use less privileged user to run
> and it would fail in the exac
śr., 13 lis 2019 o 23:37 Khem Raj napisał(a):
>
> On Wed, Nov 13, 2019 at 7:50 AM Ross Burton wrote:
> >
> > On 13/11/2019 15:04, Mark Hatle wrote:
> > >> This is because the implementation of __pthread_exit() in glibc calls
> > >> pthread_cancel() which leads to pthread_cancel_init() being calle
śr., 13 lis 2019 o 23:39 Khem Raj napisał(a):
>
> On Wed, Nov 13, 2019 at 12:34 AM Bartosz Golaszewski wrote:
> >
> > This isn't a patch as I'm not sure how to fix the right way it but it
> > seems to my that every program that calls pthread_exit() indirectly
> > rdepends on libgcc_s.so.1 being i
On Wed, Nov 13, 2019 at 12:34 AM Bartosz Golaszewski wrote:
>
> This isn't a patch as I'm not sure how to fix the right way it but it
> seems to my that every program that calls pthread_exit() indirectly
> rdepends on libgcc_s.so.1 being installed in the system (at least when
> using glibc).
>
> T
On Wed, Nov 13, 2019 at 7:50 AM Ross Burton wrote:
>
> On 13/11/2019 15:04, Mark Hatle wrote:
> >> This is because the implementation of __pthread_exit() in glibc calls
> >> pthread_cancel() which leads to pthread_cancel_init() being called in
> >> which said shared object is being loaded with dlo
On Wed, 2019-11-13 at 22:03 +0100, Bartosz Golaszewski wrote:
> śr., 13 lis 2019 o 16:04 Mark Hatle
> napisał(a):
> > On 11/13/19 2:34 AM, Bartosz Golaszewski wrote:
> > > This isn't a patch as I'm not sure how to fix the right way it
> > > but it
> > > seems to my that every program that calls pt
śr., 13 lis 2019 o 16:04 Mark Hatle napisał(a):
>
>
>
> On 11/13/19 2:34 AM, Bartosz Golaszewski wrote:
> > This isn't a patch as I'm not sure how to fix the right way it but it
> > seems to my that every program that calls pthread_exit() indirectly
> > rdepends on libgcc_s.so.1 being installed in
On 13/11/2019 15:04, Mark Hatle wrote:
This is because the implementation of __pthread_exit() in glibc calls
pthread_cancel() which leads to pthread_cancel_init() being called in
which said shared object is being loaded with dlopen(). When this
fails, the program aborts with the following error m
On 11/13/19 2:34 AM, Bartosz Golaszewski wrote:
> This isn't a patch as I'm not sure how to fix the right way it but it
> seems to my that every program that calls pthread_exit() indirectly
> rdepends on libgcc_s.so.1 being installed in the system (at least when
> using glibc).
>
> This is beca
This isn't a patch as I'm not sure how to fix the right way it but it
seems to my that every program that calls pthread_exit() indirectly
rdepends on libgcc_s.so.1 being installed in the system (at least when
using glibc).
This is because the implementation of __pthread_exit() in glibc calls
pthre
10 matches
Mail list logo
