uptime / w coredumping on RELENG11 (i386 only)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

uptime / w coredumping on RELENG11 (i386 only)

mdtancsa
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=0x28000000) 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=<value optimized out>, flags=<value
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  0x00000000 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, [hidden email]
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

mdtancsa
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=0x28000000) 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=<value optimized out>, flags=<value
> 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  0x00000000 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
<http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
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=<optimized out>) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:799
799             return (*mapbitsp);
(gdb) bt full
#0  __je_arena_mapbitsp_read (mapbitsp=<optimized out>) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:799
No locals.
#1  __je_arena_mapbits_get (chunk=0x28000000, pageind=<optimized out>)
at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:806
No locals.
#2  __je_arena_mapbits_binind_get (chunk=0x28000000, pageind=<optimized
out>)
    at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:863
        mapbits = <optimized out>
        binind = <optimized out>
#3  __je_arena_salloc (demote=<error reading variable: Cannot access
memory at address 0x0>, tsdn=<optimized out>, ptr=<optimized out>)
    at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:1384
        chunk = 0x28000000
        pageind = <optimized out>
        binind = <optimized out>
        ret = <optimized out>
#4  __je_isalloc (demote=<error reading variable: Cannot access memory
at address 0x0>, tsdn=<optimized out>, ptr=<optimized out>)
    at
/usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:951
No locals.
#5  ifree (tsd=0x28000000, ptr=<optimized out>, tcache=<optimized out>,
slow_path=<optimized out>) at jemalloc_jemalloc.c:1810
        rzsize = <error reading variable rzsize (Cannot access memory at
address 0x0)>
        usize = <optimized out>
#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=<optimized out>,
fields=<optimized out>, max_fields=<optimized out>, fmt=<optimized out>)
    at /usr/src/contrib/libxo/libxo/libxo.c:6419
        rc = <error reading variable rc (Cannot access memory at address
0x0)>
        flush_line = <optimized out>
        max_fend = <error reading variable max_fend (Cannot access
memory at address 0x0)>
        field = <optimized out>
        xfip = <optimized out>
        ftype = <optimized out>
        flags = <optimized out>
        new_fmt = <optimized out>
        new_fields = <optimized out>
        flush = <optimized out>
        flimit = <optimized out>
        min_fstart = <optimized out>
        fstart = <optimized out>
        fend = <optimized out>
#8  0x28089a1c in xo_do_emit (xop=<optimized out>, flags=<optimized
out>, fmt=0x804ad4d "{:time-of-day/%s} ")
    at /usr/src/contrib/libxo/libxo/libxo.c:6470
        fields = 0xbfbfdcf0
---Type <return> to continue, or q <return> to quit---
        max_fields = 671088640
#9  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at
/usr/src/contrib/libxo/libxo/libxo.c:6541
        xop = 0x54
        rc = <optimized out>
#10 0x08049f50 in pr_header (nowp=<optimized out>, nusers=<optimized
out>) at /usr/src/usr.bin/w/w.c:475
        avenrun = {0, 0, 0}
        buf = "\000\000\000\000\000\000\000\000
6:18PM\000/0\000\000\244\210\004\b", '\000' <repeats 28 times>,
"\062\000\000\000\247\337*\000\252^\005(s\263 (s\263
(\000\254\006(\020^\006(\002\000\000\000\230\341\277\277\300\340\277\277\264\245
(\020^\006(@\341\277\277g\026\005(\340\340\277\277\320\260\006(\210\341\277\277\020^\006(H\341\277\277\222Z\005(\020\341\277\277\000\240\006(\000\000\000\000\210\341\277\277\020^\006(\000\240\006(\000\000\000\000\000\000\000\000(\342\277\277\000\000\000\000\000\000\000\000\004\000\000\000\260\341\006(
bd\a\240]\005(t'\006(\223\220\f("...
        upbuf = <optimized out>
        tp = <optimized out>
        uptime = <optimized out>
        days = <optimized out>
        hrs = <optimized out>
        mins = <optimized out>
        secs = <optimized out>
        i = <optimized out>
#11 main (argc=<optimized out>, argv=<optimized out>) at
/usr/src/usr.bin/w/w.c:257
        buf = "\000\000\000\000\000\000\000\000
6:18PM\000/0\000\000\244\210\004\b", '\000' <repeats 28 times>,
"\062\000\000\000\247\337*\000\252^\005(s\263 (s\263
(\000\254\006(\020^\006(\002\000\000\000\230\341\277\277\300\340\277\277\264\245
(\020^\006(@\341\277\277g\026\005(\340\340\277\277\320\260\006(\210\341\277\277\020^\006(H\341\277\277\222Z\005(\020\341\277\277\000\240\006(\000\000\000\000\210\341\277\277\020^\006(\000\240\006(\000\000\000\000\000\000\000\000(\342\277\277\000\000\000\000\000\000\000\000\004\000\000\000\260\341\006(
bd\a\240]\005(t'\006(\223\220\f("...
        errbuf = "\001", '\000' <repeats 32 times>, "\260\004(", '\000'
<repeats 13 times>,
"\260\004(\000]\006(\000\000\000\000\064\260\004(\200", '\000' <repeats
47 times>, "\070\267\004(\320\t", '\000' <repeats 26 times>,
"p\262\004(p\264\004(w\001\000\000\000\000\000\000\000\000\000\000(\266\004(\b\000\000\000\350\265\004(\274\260\004(\021\000\000\000\000\261\004(
\000\000\000\021\000\000\000\001\000\000\000"...
        fn = '\000' <repeats 192 times>, "\252^\005(\\\214\004\b"...
        p = <optimized out>
        wcmd = <optimized out>
        nlistf = <optimized out>
        memf = <optimized out>
        ch = <optimized out>
        nusers = <optimized out>
        touched = <optimized out>
        nentries = <optimized out>
        kp = <optimized out>
        i = <optimized out>
        dkp = <optimized out>
        longattime = <optimized out>
---Type <return> to continue, or q <return> to quit---
        longidle = <optimized out>
        save_p = <optimized out>
        x_suffix = <optimized out>
        dot = <optimized out>
        stp = <optimized out>
(gdb)
(gdb)

and the debug output of w using gdb from the ports

 # /usr/local/bin/gdb /usr/bin/w w.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
<http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/w...Reading symbols from
/usr/lib/debug//usr/bin/w.debug...done.
done.
[New LWP 100130]
Core was generated by `w'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __je_arena_mapbitsp_read (mapbitsp=<optimized out>) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:799
799             return (*mapbitsp);
(gdb) bt full
#0  __je_arena_mapbitsp_read (mapbitsp=<optimized out>) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:799
No locals.
#1  __je_arena_mapbits_get (chunk=0x28000000, pageind=<optimized out>)
at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:806
No locals.
#2  __je_arena_mapbits_binind_get (chunk=0x28000000, pageind=<optimized
out>)
    at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:863
        mapbits = <optimized out>
        binind = <optimized out>
#3  __je_arena_salloc (demote=<error reading variable: Cannot access
memory at address 0x0>, tsdn=<optimized out>, ptr=<optimized out>)
    at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena.h:1384
        chunk = 0x28000000
        pageind = <optimized out>
        binind = <optimized out>
        ret = <optimized out>
#4  __je_isalloc (demote=<error reading variable: Cannot access memory
at address 0x0>, tsdn=<optimized out>, ptr=<optimized out>)
    at
/usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:951
No locals.
#5  ifree (tsd=0x28000000, ptr=<optimized out>, tcache=<optimized out>,
slow_path=<optimized out>) at jemalloc_jemalloc.c:1810
        rzsize = <error reading variable rzsize (Cannot access memory at
address 0x0)>
        usize = <optimized out>
#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=<optimized out>,
fields=<optimized out>, max_fields=<optimized out>, fmt=<optimized out>)
    at /usr/src/contrib/libxo/libxo/libxo.c:6419
        rc = <error reading variable rc (Cannot access memory at address
0x0)>
        flush_line = <optimized out>
        max_fend = <error reading variable max_fend (Cannot access
memory at address 0x0)>
        field = <optimized out>
        xfip = <optimized out>
        ftype = <optimized out>
        flags = <optimized out>
        new_fmt = <optimized out>
        new_fields = <optimized out>
        flush = <optimized out>
        flimit = <optimized out>
        min_fstart = <optimized out>
        fstart = <optimized out>
        fend = <optimized out>
#8  0x28089a1c in xo_do_emit (xop=<optimized out>, flags=<optimized
out>, fmt=0x804ad4d "{:time-of-day/%s} ")
    at /usr/src/contrib/libxo/libxo/libxo.c:6470
        fields = 0xbfbfdcf0
---Type <return> to continue, or q <return> to quit---
        max_fields = 671088640
#9  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at
/usr/src/contrib/libxo/libxo/libxo.c:6541
        xop = 0x54
        rc = <optimized out>
#10 0x08049f50 in pr_header (nowp=<optimized out>, nusers=<optimized
out>) at /usr/src/usr.bin/w/w.c:475
        avenrun = {0, 0, 0}
        buf = "\000\000\000\000\000\000\000\000
6:21PM\000/0\000\000\244\210\004\b", '\000' <repeats 28 times>,
"\062\000\000\000\247\337*\000\252^\005(s\263 (s\263
(\000\254\006(\020^\006(\002\000\000\000\230\341\277\277\300\340\277\277\264\245
(\020^\006(@\341\277\277g\026\005(\340\340\277\277\320\260\006(\210\341\277\277\020^\006(H\341\277\277\222Z\005(\020\341\277\277\000\240\006(\000\000\000\000\210\341\277\277\020^\006(\000\240\006(\000\000\000\000\000\000\000\000(\342\277\277\000\000\000\000\000\000\000\000\004\000\000\000\260\341\006(
bd\a\240]\005(t'\006(\223\220\f("...
        upbuf = <optimized out>
        tp = <optimized out>
        uptime = <optimized out>
        days = <optimized out>
        hrs = <optimized out>
        mins = <optimized out>
        secs = <optimized out>
        i = <optimized out>
#11 main (argc=<optimized out>, argv=<optimized out>) at
/usr/src/usr.bin/w/w.c:257
        buf = "\000\000\000\000\000\000\000\000
6:21PM\000/0\000\000\244\210\004\b", '\000' <repeats 28 times>,
"\062\000\000\000\247\337*\000\252^\005(s\263 (s\263
(\000\254\006(\020^\006(\002\000\000\000\230\341\277\277\300\340\277\277\264\245
(\020^\006(@\341\277\277g\026\005(\340\340\277\277\320\260\006(\210\341\277\277\020^\006(H\341\277\277\222Z\005(\020\341\277\277\000\240\006(\000\000\000\000\210\341\277\277\020^\006(\000\240\006(\000\000\000\000\000\000\000\000(\342\277\277\000\000\000\000\000\000\000\000\004\000\000\000\260\341\006(
bd\a\240]\005(t'\006(\223\220\f("...
        errbuf = "\001", '\000' <repeats 32 times>, "\260\004(", '\000'
<repeats 13 times>,
"\260\004(\000]\006(\000\000\000\000\064\260\004(\200", '\000' <repeats
47 times>, "\070\267\004(\320\t", '\000' <repeats 26 times>,
"p\262\004(p\264\004(w\001\000\000\000\000\000\000\000\000\000\000(\266\004(\b\000\000\000\350\265\004(\274\260\004(\021\000\000\000\000\261\004(
\000\000\000\021\000\000\000\001\000\000\000"...
        fn = '\000' <repeats 192 times>, "\252^\005(\\\214\004\b"...
        p = <optimized out>
        wcmd = <optimized out>
        nlistf = <optimized out>
        memf = <optimized out>
        ch = <optimized out>
        nusers = <optimized out>
        touched = <optimized out>
        nentries = <optimized out>
        kp = <optimized out>
        i = <optimized out>
        dkp = <optimized out>
        longattime = <optimized out>
---Type <return> to continue, or q <return> to quit---
        longidle = <optimized out>
        save_p = <optimized out>
        x_suffix = <optimized out>
        dot = <optimized out>
        stp = <optimized out>
(gdb)





--
-------------------
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, [hidden email]
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Dimitry Andric-4
On 15 May 2018, at 20:22, Mike Tancsa <[hidden email]> 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=0x28000000) 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=<value optimized out>, flags=<value
>> 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  0x00000000 in ?? ()
>> Current language:  auto; currently minimal
>> (gdb)
>>
>> I dont have debug symbols yet
>>
>> r333636
>>
>> Anyone else see this ?
See <https://bugs.freebsd.org/227552>.  There is a fix coming up.

-Dimitry


signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

mdtancsa
On 5/15/2018 2:31 PM, Dimitry Andric wrote:
> On 15 May 2018, at 20:22, Mike Tancsa <[hidden email]> wrote:
>>
>>>
>>> Anyone else see this ?
>
> See <https://bugs.freebsd.org/227552>.  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, [hidden email]
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Dimitry Andric-4
On 16 May 2018, at 15:54, Mike Tancsa <[hidden email]> wrote:

>
> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>> On 15 May 2018, at 20:22, Mike Tancsa <[hidden email]> wrote:
>>>
>>>>
>>>> Anyone else see this ?
>>
>> See <https://bugs.freebsd.org/227552>.  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 (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Dewayne Geraghty-4
On 17/05/2018 7:17 AM, Dimitry Andric wrote:

> On 16 May 2018, at 15:54, Mike Tancsa <[hidden email]> wrote:
>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>>> On 15 May 2018, at 20:22, Mike Tancsa <[hidden email]> wrote:
>>>>> Anyone else see this ?
>>> See <https://bugs.freebsd.org/227552>.  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&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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Dimitry Andric-4
On 17 May 2018, at 02:01, Dewayne Geraghty <[hidden email]> wrote:

>
> On 17/05/2018 7:17 AM, Dimitry Andric wrote:
>> On 16 May 2018, at 15:54, Mike Tancsa <[hidden email]> wrote:
>>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>>>> On 15 May 2018, at 20:22, Mike Tancsa <[hidden email]> wrote:
>>>>>> Anyone else see this ?
>>>> See <https://bugs.freebsd.org/227552>.  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&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 (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

mdtancsa
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, [hidden email]
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"