glibc make check fails...

glibc make check fails...

[Andreas Jaeger]

All thread tests currently fail for me - yesterday they worked fine:

$ GCONV_PATH=/builds/glibc/main/iconvdata LC_ALL=C   /builds/glibc/main/elf/ld-linux.so.2 --library-path /builds/glibc/main:/builds/glibc/main/math:/builds/glibc/main/elf:/builds/glibc/main/dlfcn:/builds/glibc/main/nss:/builds/glibc/main/nis:/builds/glibc/main/rt:/builds/glibc/main/resolv:/builds/glibc/main/crypt:/builds/glibc/main/linuxthreads /builds/glibc/main/linuxthreads/ex1
Segmentation fault

I run configure as:
/cvs/libc/configure  --disable-profile --enable-add-ons --prefix=/builds/test-install --enable-kernel=2.4.18

strace shows:
open("/builds/glibc/main/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\"Y\1\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=11459957, ...}) = 0
mmap2(NULL, 1113892, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40050000
mprotect(0x40157000, 36644, PROT_NONE)  = 0
mmap2(0x40157000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x107) = 0x40157000
mmap2(0x4015c000, 16164, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015c000
close(3)                                = 0
shutdown(-1073745480, 1073795200)       = -1 ENOSYS (Function not implemented)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: glibc make check fails...

[Roland McGrath]

My build didn't have --enable-kernel=2.4.18 but now I've tried that and
reproduced the crash, so I will fix it shortly.

Re: glibc make check fails...

[Roland McGrath]

Ok, I was wrong.  I actually can only reproduce this in a build that's
using not 2.4.18 headers but newer headers that define __NR_set_thread_area
(when running on a 2.4.18 kernel that doesn't have the system call).

If that is your situation too, are you sure it worked before?  If that is
not your situation, then I can't reproduce your situation and you will have
to find some more information for me.

The crash I see is from the useldt.h macros' use of INLINE_SYSCALL
resulting in it calling __errno_location, which bombs when %gs isn't set up
yet.  AFAICT the useldt.h macros have the very same issue with errno not
being set up as the TLS macros have (errno TLS var vs __errno_location
definition from libpthread, but both need %gs to be set up or they crash).
So I am going to consolidate those macros and use the versions that avoid
trying to set errno for both.

Re: glibc make check fails...

[Andreas Jaeger]

Roland McGrath <roland@redhat.com> writes:

> Ok, I was wrong.  I actually can only reproduce this in a build that's
> using not 2.4.18 headers but newer headers that define __NR_set_thread_area
> (when running on a 2.4.18 kernel that doesn't have the system call).

My kernel headers do not have that call.

>
> If that is your situation too, are you sure it worked before?  If that is
> not your situation, then I can't reproduce your situation and you will have
> to find some more information for me.
>
> The crash I see is from the useldt.h macros' use of INLINE_SYSCALL
> resulting in it calling __errno_location, which bombs when %gs isn't set up
> yet.  AFAICT the useldt.h macros have the very same issue with errno not
> being set up as the TLS macros have (errno TLS var vs __errno_location
> definition from libpthread, but both need %gs to be set up or they crash).
> So I am going to consolidate those macros and use the versions that avoid
> trying to set errno for both.

Unfortunatly my gdb cannot debug this but it's somewhere in the
libpthread startup code:

22306:  calling init: /builds/test-install/lib/libpthread.so.0
22306:
22306:  symbol=__errno_location;  lookup in file=linuxthreads/ex3
22306:  symbol=__errno_location;  lookup in file=/builds/test-install/lib/libpthread.so.0
22306:  binding file /builds/test-install/lib/libpthread.so.0 to /builds/test-install/lib/libpthread.so.0: normal symbol `__errno_location' [GLIBC_2.0]
Segmentation fault

Without the --enable-kernel=2.4.18 everything works, so it seems to be
a problem with the useldt code,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: glibc make check fails...

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:

> The crash I see is from the useldt.h macros' use of INLINE_SYSCALL
> resulting in it calling __errno_location, which bombs when %gs isn't set up
> yet.  AFAICT the useldt.h macros have the very same issue with errno not
> being set up as the TLS macros have (errno TLS var vs __errno_location
> definition from libpthread,

This is why the macros in <tls.h> don't use INLINE_SYSCALL.  I should
have caught this before.  The answer is torewrite the code a bit which
is trivial.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9lzvR2ijCOnn/RHQRAlgwAJ0fMZaSaXMcXC5yMCPwCXpVcHAtDQCdF03p
PHOwddQvR+/13VOsfC/NBlQ=
=udhH
-----END PGP SIGNATURE-----

Re: glibc make check fails...

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Jaeger wrote:
> All thread tests currently fail for me - yesterday they worked fine:
> 
> $ GCONV_PATH=/builds/glibc/main/iconvdata LC_ALL=C   /builds/glibc/main/elf/ld-linux.so.2 --library-path /builds/glibc/main:/builds/glibc/main/math:/builds/glibc/main/elf:/builds/glibc/main/dlfcn:/builds/glibc/main/nss:/builds/glibc/main/nis:/builds/glibc/main/rt:/builds/glibc/main/resolv:/builds/glibc/main/crypt:/builds/glibc/main/linuxthreads /builds/glibc/main/linuxthreads/ex1
> Segmentation fault

Try the current code.  I haven't actually build it yet but it should at
least be very close to working.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9l0MN2ijCOnn/RHQRAjn/AJsErOL3x4RJnkAHRJyGyyJ+tN8IUQCfVxwj
QTSF6sIXsDuzQxYy43QDpaI=
=G14X
-----END PGP SIGNATURE-----

Re: glibc make check fails...

[Roland McGrath]

> This is why the macros in <tls.h> don't use INLINE_SYSCALL.  I should
> have caught this before.  The answer is torewrite the code a bit which
> is trivial.

Yes, just not quite trivial enough for me to do blearily at 5am today. :)

However, this does not explain AJ's crash because he has a build with no
__NR_set_thread_area.  It must be the modify_ldt call failing, for which we
have no explanation and AFAIK noone else has seen it.

In principle the modify_ldt call can fail too, and it would be preferable
to crash in abort as intended rather than crash in the errno access.
Also I would be happier not having the duplication between tls.h and useldt.h.

Re: glibc make check fails...

[Roland McGrath]

> My kernel headers do not have that call.

Then it is very mysterious!

> Unfortunatly my gdb cannot debug this but it's somewhere in the
> libpthread startup code:

Do you get a core dump you can look at?

> 22306:  calling init: /builds/test-install/lib/libpthread.so.0
> 22306:
> 22306:  symbol=__errno_location;  lookup in file=linuxthreads/ex3
> 22306:  symbol=__errno_location;  lookup in file=/builds/test-install/lib/libpthread.so.0
> 22306:  binding file /builds/test-install/lib/libpthread.so.0 to /builds/test-install/lib/libpthread.so.0: normal symbol `__errno_location' [GLIBC_2.0]
> Segmentation fault

That looks exactly like the failure you'd expect if the set_thread_area
call (via INLINE_SYSCALL) or the modify_ldt call had failed.  Since you
don't have set_thread_area, it must be modify_ldt but I don't think anyone
else has seen that fail.

Re: glibc make check fails...

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:

> However, this does not explain AJ's crash because he has a build with no
> __NR_set_thread_area.  It must be the modify_ldt call failing, for which we
> have no explanation and AFAIK noone else has seen it.

If this happens the system is in deep trouble anyway.


> In principle the modify_ldt call can fail too, and it would be preferable
> to crash in abort as intended rather than crash in the errno access.
> Also I would be happier not having the duplication between tls.h and useldt.h.

The new thread code has all this cleaned up.  It's just not worth it to
worry about the old code too much.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9l3f72ijCOnn/RHQRAsefAKDIxY1NFcEWVMHGsGqyeirIngR9ogCgzeI/
j+l8PBeIK3r9tTAKYDLSzvY=
=XJTG
-----END PGP SIGNATURE-----

Re: glibc make check fails...

[Roland McGrath]

> If this happens the system is in deep trouble anyway.

Indeed so.  But the deeper the trouble, the more every little bit less of
confusion can help the poor sucker trying to find the trouble.

> The new thread code has all this cleaned up.  It's just not worth it to
> worry about the old code too much.

Agreed.

Re: glibc make check fails...

[Andreas Jaeger]

Roland McGrath <roland@redhat.com> writes:

>> My kernel headers do not have that call.
>
> Then it is very mysterious!
>
>> Unfortunatly my gdb cannot debug this but it's somewhere in the
>> libpthread startup code:
>
> Do you get a core dump you can look at?
>
>> 22306:  calling init: /builds/test-install/lib/libpthread.so.0
>> 22306:
>> 22306:  symbol=__errno_location;  lookup in file=linuxthreads/ex3
>> 22306:  symbol=__errno_location;  lookup in file=/builds/test-install/lib/libpthread.so.0
>> 22306:  binding file /builds/test-install/lib/libpthread.so.0 to /builds/test-install/lib/libpthread.so.0: normal symbol `__errno_location' [GLIBC_2.0]
>> Segmentation fault
>
> That looks exactly like the failure you'd expect if the set_thread_area
> call (via INLINE_SYSCALL) or the modify_ldt call had failed.  Since you
> don't have set_thread_area, it must be modify_ldt but I don't think anyone
> else has seen that fail.

I tried this morning's (12 hours ago) CVS  and that worked fine.  I'm
retrying current CVS (as of 10 minutes ago) and if you do not hear
anything in the next two hours, the problems are fixed for me,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: glibc make check fails...

[Andreas Jaeger]

Just for the record since make was fast:

make check passes everything (except the known regex12 failure) on my
dual athlon configured with:
/cvs/libc/configure  --disable-profile --enable-add-ons --prefix=/builds/test-install --enable-kernel=2.4.18

So, this leaves as only known problem the buggy --with-tls option,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj