Re: dlclose segfaults on x86_64
On 01/11/2012 16.26, Natanael Copa wrote:
> On Fri, Oct 5, 2012 at 1:46 PM, Natanael Copa wrote:
>> building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64.
> ...
>> Core was generated by
>> `/home/ncopa/aports/main/vlc/src/vlc-2.0.3/bin/.libs/lt-vlc-cache-gen
>> ../modules'.
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
>> at libc/stdlib/malloc-standard/free.c:324
>> 324 p->fd = *fb;
>> (gdb) bt
>> #0 0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
>> at libc/stdlib/malloc-standard/free.c:324
>> #1 0x7f9e5f0843d6 in do_dlclose (vhandle=0x7f9e60ca7be0, need_fini=1)
>> at ldso/libdl/libdl.c:960
>> #2 0x7f9e5f084a47 in dlclose (vhandle=0x7f9e60ca7be0)
>> at ldso/libdl/libdl.c:1063
>> #3 0x7f9e5ff06e1c in module_Unload (handle=)
>> at posix/plugin.c:89
> ...
>
> Does not seem like anybody really cares, but for the record, Timo
> Teräs solved it with:
> --- ./ldso/libdl/libdl.c.orig
> +++ ./ldso/libdl/libdl.c
> @@ -951,8 +951,8 @@
>
> dtv_t *dtv = THREAD_DTV ();
>
> -
> _dl_assert(!(dtv[tls_lmap->l_tls_modid].pointer.is_static));
> - if
> (dtv[tls_lmap->l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
> + if
> (!(dtv[tls_lmap->l_tls_modid].pointer.is_static) &&
> +
> dtv[tls_lmap->l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
> /* Note that free is
> called for NULL is well. We
> deallocate even if it
> is this dtv entry we are
> supposed to load. The
> reason is that we call
>
>
> Downloadable patch is available here:
> http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/uclibc-dlclose-fix.patch
>
Can we have a well git formed patch sent to this list, unless I've
missed it ?
Thanks,
Carmelo
> I have a relatively small testcase application that can reproduce it
> (using vlc's plugins)
>
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: dlclose segfaults on x86_64
On Fri, Oct 5, 2012 at 1:46 PM, Natanael Copa wrote:
> building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64.
...
> Core was generated by
> `/home/ncopa/aports/main/vlc/src/vlc-2.0.3/bin/.libs/lt-vlc-cache-gen
> ../modules'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
> at libc/stdlib/malloc-standard/free.c:324
> 324 p->fd = *fb;
> (gdb) bt
> #0 0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
> at libc/stdlib/malloc-standard/free.c:324
> #1 0x7f9e5f0843d6 in do_dlclose (vhandle=0x7f9e60ca7be0, need_fini=1)
> at ldso/libdl/libdl.c:960
> #2 0x7f9e5f084a47 in dlclose (vhandle=0x7f9e60ca7be0)
> at ldso/libdl/libdl.c:1063
> #3 0x7f9e5ff06e1c in module_Unload (handle=)
> at posix/plugin.c:89
...
Does not seem like anybody really cares, but for the record, Timo
Teräs solved it with:
--- ./ldso/libdl/libdl.c.orig
+++ ./ldso/libdl/libdl.c
@@ -951,8 +951,8 @@
dtv_t *dtv = THREAD_DTV ();
-
_dl_assert(!(dtv[tls_lmap->l_tls_modid].pointer.is_static));
- if
(dtv[tls_lmap->l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
+ if
(!(dtv[tls_lmap->l_tls_modid].pointer.is_static) &&
+
dtv[tls_lmap->l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
/* Note that free is
called for NULL is well. We
deallocate even if it
is this dtv entry we are
supposed to load. The
reason is that we call
Downloadable patch is available here:
http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/uclibc-dlclose-fix.patch
I have a relatively small testcase application that can reproduce it
(using vlc's plugins)
--
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: dlclose segfaults on x86_64
On Fri, Oct 5, 2012 at 1:46 PM, Natanael Copa wrote: > Hi, > > I have an issue that I suspect is a bug in uclibc, 0.9.33.2 and gcc-4.7 > > building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64. > On 32bit x86 it works. Looking at the commits... This looks like doing evil stuff on 64 bit: http://git.uclibc.org/uClibc/commit/ldso?h=0.9.33&id=9b42da7d0558884e2a3cc9a8674ccfc752369610 Infact, that 'unsigned int' and 'addr' looks suspicious. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
