Re: uptime / w coredumping on RELENG11 (i386 only)

[Mike Tancsa]

On 5/17/2018 7:03 AM, Dimitry Andric wrote:
> 
>> Its a little disappointing to hear that the stripping process breaks the
>> output, if applied >1.
> 
> And that was actually the bug.  Note that this only happens for TLS
> segments, which are not used very often.  That is probably the reason
> we never ran into problems before.

BTW, Is there some uncertainty about the proposed patch / solution ? I
would have thought it would have been MFC'd ?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dimitry Andric]

On 17 May 2018, at 02:01, Dewayne Geraghty 
 wrote:
> 
> On 17/05/2018 7:17 AM, Dimitry Andric wrote:
>> On 16 May 2018, at 15:54, Mike Tancsa  wrote:
>>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
 On 15 May 2018, at 20:22, Mike Tancsa  wrote:
>> Anyone else see this ?
 See .  There is a fix coming up.
>>> I tried the patch and did a full rebuild and it indeed fixed the problem
>>> for me.  Is the bug potentially more wide spread that just libxo ? Also
>>> does it possibly affect amd64, just in a non obvious way ?
>> Yes to both, at least theoretically.  The problem is actually in
>> elftoolchain's strip command, which can mess up the TLS section in an
>> executable or shared library.  When the dynamic linker loads such a bad
>> file, it will setup incorrect TLS data, which can lead to crashes.
>> 
>> In case of libxo.so.0, this appears to have been caused by clang 6
>> giving a slightly different ELF layout than clang 5.  During buildworld,
>> libxo.so.0 is built with debugging information, which is later copied
>> to a libxo.so.0.debug file, while it is removed from the original
>> libxo.so.0 file.
>> 
>> Up to this point, everything is still fine with libxo.so.0, still, but
>> during installworld, the file is stripped *again*, by install -s (this
>> is something we should revisit because it seems no longer useful).  This
>> second round of stripping messes up the TLS section.
>> 
>> -Dimitry
>> 
> Revisit? Perhaps, but it seems that its a regression against clang6 over
> clang5.

Well, my argument is that as long as any compiler and linker spit out a
valid ELF file, strip should not corrupt it. :)

And for certain, running strip twice on the same file should never
change it (except for maybe timestamp-related fields).


> Looking at
> https://svnweb.freebsd.org/base?view=revision=333600
> its appears that the section flags are correctly applied now.  When
> 333600 enters 11.1Beta?, do you think the build/installation process
> requires revision?

No, it should be enough to fix strip.  In the installworld stage, the
copy of strip built during the cross-tools stage is used.

What I meant with revisiting this, is that historically we've stripped
executables and shared libraries during installworld, as those could
optionally have been built with debug information.

But since the introduction of /usr/lib/debug, this is no longer the
case: effectively, everything is built *with* debug information, and
this debug information is already stripped out and moved to separate
files during the buildworld stage.

Therefore, it is no longer necessary to strip those files again.


> Its a little disappointing to hear that the stripping process breaks the
> output, if applied >1.

And that was actually the bug.  Note that this only happens for TLS
segments, which are not used very often.  That is probably the reason
we never ran into problems before.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dewayne Geraghty]

On 17/05/2018 7:17 AM, Dimitry Andric wrote:
> On 16 May 2018, at 15:54, Mike Tancsa  wrote:
>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>>> On 15 May 2018, at 20:22, Mike Tancsa  wrote:
> Anyone else see this ?
>>> See .  There is a fix coming up.
>> I tried the patch and did a full rebuild and it indeed fixed the problem
>> for me.  Is the bug potentially more wide spread that just libxo ? Also
>> does it possibly affect amd64, just in a non obvious way ?
> Yes to both, at least theoretically.  The problem is actually in
> elftoolchain's strip command, which can mess up the TLS section in an
> executable or shared library.  When the dynamic linker loads such a bad
> file, it will setup incorrect TLS data, which can lead to crashes.
>
> In case of libxo.so.0, this appears to have been caused by clang 6
> giving a slightly different ELF layout than clang 5.  During buildworld,
> libxo.so.0 is built with debugging information, which is later copied
> to a libxo.so.0.debug file, while it is removed from the original
> libxo.so.0 file.
>
> Up to this point, everything is still fine with libxo.so.0, still, but
> during installworld, the file is stripped *again*, by install -s (this
> is something we should revisit because it seems no longer useful).  This
> second round of stripping messes up the TLS section.
>
> -Dimitry
>
Revisit? Perhaps, but it seems that its a regression against clang6 over
clang5.  Looking at
https://svnweb.freebsd.org/base?view=revision=333600
its appears that the section flags are correctly applied now.  When
333600 enters 11.1Beta?, do you think the build/installation process
requires revision?

Its a little disappointing to hear that the stripping process breaks the
output, if applied >1.

-- 
Influence national support against IP address spoofing (pretending to be 
someone else), refer: http://www.bcp38.info/index.php/Main_Page

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dimitry Andric]

On 16 May 2018, at 15:54, Mike Tancsa  wrote:
> 
> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>> On 15 May 2018, at 20:22, Mike Tancsa  wrote:
>>> 
 
 Anyone else see this ?
>> 
>> See .  There is a fix coming up.
> 
> I tried the patch and did a full rebuild and it indeed fixed the problem
> for me.  Is the bug potentially more wide spread that just libxo ? Also
> does it possibly affect amd64, just in a non obvious way ?

Yes to both, at least theoretically.  The problem is actually in
elftoolchain's strip command, which can mess up the TLS section in an
executable or shared library.  When the dynamic linker loads such a bad
file, it will setup incorrect TLS data, which can lead to crashes.

In case of libxo.so.0, this appears to have been caused by clang 6
giving a slightly different ELF layout than clang 5.  During buildworld,
libxo.so.0 is built with debugging information, which is later copied
to a libxo.so.0.debug file, while it is removed from the original
libxo.so.0 file.

Up to this point, everything is still fine with libxo.so.0, still, but
during installworld, the file is stripped *again*, by install -s (this
is something we should revisit because it seems no longer useful).  This
second round of stripping messes up the TLS section.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: uptime / w coredumping on RELENG11 (i386 only)

[Mike Tancsa]

On 5/15/2018 2:31 PM, Dimitry Andric wrote:
> On 15 May 2018, at 20:22, Mike Tancsa  wrote:
>>
>>>
>>> Anyone else see this ?
> 
> See .  There is a fix coming up.
> 

Hi,

I tried the patch and did a full rebuild and it indeed fixed the problem
for me.  Is the bug potentially more wide spread that just libxo ? Also
does it possibly affect amd64, just in a non obvious way ?

---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dimitry Andric]

On 15 May 2018, at 20:22, Mike Tancsa  wrote:
> 
> On 5/15/2018 2:10 PM, Mike Tancsa wrote:
>> Wasnt sure if it was my VM, so i took a stock 11.1R installed it on a
>> new VM and updated the sources to today.  Stock GENERIC kernel
>> 
>> **  this is i386 **
>> 
>> 
>> via truss (w)
>> 
>> access("/etc/localtime",R_OK)= 0 (0x0)
>> open("/etc/localtime",O_RDONLY,06605223677)  = 5 (0x5)
>> fstat(5,{ mode=-r--r--r-- ,inode=1367764,size=118,blksize=32768 }) = 0 (0x0)
>> read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,29000) = 118 (0x76)
>> close(5) = 0 (0x0)
>> SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x28000184
>> process killed, signal = 11 (core dumped)
>> 
>> (gdb) bt
>> #0  ifree (tsd=0x2800) at arena.h:799
>> #1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
>> #2  0x2808bb07 in xo_do_emit_fields () at
>> /usr/src/contrib/libxo/libxo/libxo.c:6419
>> #3  0x28089a1c in xo_do_emit (xop=, flags=> optimized out>, fmt=0x804ad4d "{:time-of-day/%s} ")
>>at /usr/src/contrib/libxo/libxo/libxo.c:6470
>> #4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at
>> /usr/src/contrib/libxo/libxo/libxo.c:6541
>> #5  0x08049f50 in ?? ()
>> #6  0x0804ad4d in ?? ()
>> #7  0xbfbfe044 in ?? ()
>> #8  0x28065e58 in list_global () from /libexec/ld-elf.so.1
>> #9  0x in ?? ()
>> Current language:  auto; currently minimal
>> (gdb)
>> 
>> I dont have debug symbols yet
>> 
>> r333636
>> 
>> Anyone else see this ?

See .  There is a fix coming up.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: uptime / w coredumping on RELENG11 (i386 only)

[Mike Tancsa]

On 5/15/2018 2:10 PM, Mike Tancsa wrote:
> Wasnt sure if it was my VM, so i took a stock 11.1R installed it on a
> new VM and updated the sources to today.  Stock GENERIC kernel
> 
> **  this is i386 **
> 
> 
> via truss (w)
> 
> access("/etc/localtime",R_OK)= 0 (0x0)
> open("/etc/localtime",O_RDONLY,06605223677)  = 5 (0x5)
> fstat(5,{ mode=-r--r--r-- ,inode=1367764,size=118,blksize=32768 }) = 0 (0x0)
> read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,29000) = 118 (0x76)
> close(5) = 0 (0x0)
> SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x28000184
> process killed, signal = 11 (core dumped)
> 
> (gdb) bt
> #0  ifree (tsd=0x2800) at arena.h:799
> #1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
> #2  0x2808bb07 in xo_do_emit_fields () at
> /usr/src/contrib/libxo/libxo/libxo.c:6419
> #3  0x28089a1c in xo_do_emit (xop=, flags= optimized out>, fmt=0x804ad4d "{:time-of-day/%s} ")
> at /usr/src/contrib/libxo/libxo/libxo.c:6470
> #4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at
> /usr/src/contrib/libxo/libxo/libxo.c:6541
> #5  0x08049f50 in ?? ()
> #6  0x0804ad4d in ?? ()
> #7  0xbfbfe044 in ?? ()
> #8  0x28065e58 in list_global () from /libexec/ld-elf.so.1
> #9  0x in ?? ()
> Current language:  auto; currently minimal
> (gdb)
> 
> I dont have debug symbols yet
> 
> r333636
> 
> Anyone else see this ?
> 


and for uptime

fstat(5,{ mode=-rw-r--r-- ,inode=4173831,size=591,blksize=32768 }) = 0 (0x0)
fstat(5,{ mode=-rw-r--r-- ,inode=4173831,size=591,blksize=32768 }) = 0 (0x0)
read(5,"\^A\0\^ElBuW\M-K\M-^\0\0\0\0\0\0"...,985) = 591 (0x24f)
stat("/dev/ttyv0",{ mode=crw--- ,inode=73,size=0,blksize=4096 }) = 0
(0x0)
stat("/dev/pts/0",{ mode=crw--w ,inode=89,size=0,blksize=4096 }) = 0
(0x0)
read(5,0x28628400,985)   = 0 (0x0)
close(5) = 0 (0x0)
access("/etc/localtime",R_OK)= 0 (0x0)
open("/etc/localtime",O_RDONLY,06605223677)  = 5 (0x5)
fstat(5,{ mode=-r--r--r-- ,inode=1367764,size=118,blksize=32768 }) = 0 (0x0)
read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,29000) = 118 (0x76)
close(5) = 0 (0x0)
SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x28000184
process killed, signal = 11 (core dumped)

and using gdb from the ports

 # /usr/local/bin/gdb uptime uptime.core
GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd11.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from uptime...Reading symbols from
/usr/lib/debug//usr/bin/w.debug...done.
done.
[New LWP 100130]
Core was generated by `uptime'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __je_arena_mapbitsp_read (mapbitsp=) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:799
799 return (*mapbitsp);
(gdb) bt full
#0  __je_arena_mapbitsp_read (mapbitsp=) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:799
No locals.
#1  __je_arena_mapbits_get (chunk=0x2800, pageind=)
at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:806
No locals.
#2  __je_arena_mapbits_binind_get (chunk=0x2800, pageind=)
at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:863
mapbits = 
binind = 
#3  __je_arena_salloc (demote=, tsdn=, ptr=)
at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:1384
chunk = 0x2800
pageind = 
binind = 
ret = 
#4  __je_isalloc (demote=, tsdn=, ptr=)
at
/usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:951
No locals.
#5  ifree (tsd=0x2800, ptr=, tcache=,
slow_path=) at jemalloc_jemalloc.c:1810
rzsize = 
usize = 
#6  0x2814b506 in __free (ptr=0x280601ef
<__pthread_cleanup_push_imp_int+31>) at jemalloc_jemalloc.c:1935
No locals.
#7  0x2808bb07 in xo_do_emit_fields (xop=,
fields=, max_fields=, fmt=)
at /usr/src/contrib/libxo/libxo/libxo.c:6419
rc = 
flush_line = 
max_fend = 
field = 
xfip = 
ftype = 
flags = 
new_fmt = 
new_fields = 
flush = 
flimit = 
min_fstart = 
fstart = 
fend = 
#8  0x28089a1c in xo_do_emit (xop=, flags=, fmt=0x804ad4d "{:time-of-day/%s} ")
at 

uptime / w coredumping on RELENG11 (i386 only)

[Mike Tancsa]

Wasnt sure if it was my VM, so i took a stock 11.1R installed it on a
new VM and updated the sources to today.  Stock GENERIC kernel

**  this is i386 **


via truss (w)

access("/etc/localtime",R_OK)= 0 (0x0)
open("/etc/localtime",O_RDONLY,06605223677)  = 5 (0x5)
fstat(5,{ mode=-r--r--r-- ,inode=1367764,size=118,blksize=32768 }) = 0 (0x0)
read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,29000) = 118 (0x76)
close(5) = 0 (0x0)
SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x28000184
process killed, signal = 11 (core dumped)

(gdb) bt
#0  ifree (tsd=0x2800) at arena.h:799
#1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
#2  0x2808bb07 in xo_do_emit_fields () at
/usr/src/contrib/libxo/libxo/libxo.c:6419
#3  0x28089a1c in xo_do_emit (xop=, flags=, fmt=0x804ad4d "{:time-of-day/%s} ")
at /usr/src/contrib/libxo/libxo/libxo.c:6470
#4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at
/usr/src/contrib/libxo/libxo/libxo.c:6541
#5  0x08049f50 in ?? ()
#6  0x0804ad4d in ?? ()
#7  0xbfbfe044 in ?? ()
#8  0x28065e58 in list_global () from /libexec/ld-elf.so.1
#9  0x in ?? ()
Current language:  auto; currently minimal
(gdb)

I dont have debug symbols yet

r333636

Anyone else see this ?
-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"