segfault in libc.so

segfault in libc.so

[stephen Turner]

[-- Attachment #1.1: Type: text/plain, Size: 684 bytes --]

I am getting the following strace errors from as and ldd (created as a link
pointed to libc.so) i have also seen a segfault from a dynamically linked
ld ar and ccom.

For this particular strace I compiled musl with binutils-2.24 and
pcc-20150228 (as well as a previous version) with the configure settigs
--disable-gcc-wrapper and --target=i486-linux-musl then booted the system
and called strace as and strace ldd libc.so respectively. The rest of the
system was compiled with cflags -O0 -march=i486 and ldflags -static

If anyone has a moment to look into it i would greatly appreciate it and i
will be happy to provide anything else that helps diagnose the issue.

thanks
stephen.

[-- Attachment #1.2: Type: text/html, Size: 807 bytes --]

[-- Attachment #2: as.strace --]
[-- Type: application/octet-stream, Size: 180 bytes --]

execve("/usr/bin/as", ["/usr/bin/as"], [/* 9 vars */]) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xb7745970} ---
+++ killed by SIGSEGV +++
Segmentation fault

[-- Attachment #3: libc.strace --]
[-- Type: application/octet-stream, Size: 809 bytes --]

execve("/bin/ldd", ["/bin/ldd", "/usr/lib/libc.so"], [/* 9 vars */]) = 0
open("/usr/lib/libc.so", O_RDONLY|O_LARGEFILE) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\307\2\0004\0\0\0"..., 936) = 936
mmap2(NULL, 815104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb769a000
mmap2(0xb7732000, 192512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x98000) = 0xb7732000
mmap2(0xb775f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb775f000
mprotect(0xb769a000, 815104, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
close(3)                                = 0
writev(1, [{"\t/bin/ldd (0xb7764000)\n", 23}, {NULL, 0}], 2	/bin/ldd (0xb7764000)
) = 23
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xb77f5970} ---
+++ killed by SIGSEGV +++
Segmentation fault

Re: segfault in libc.so

[Szabolcs Nagy]

* stephen Turner <stephen.n.turner@gmail.com> [2015-03-03 01:00:31 -0500]:
> I am getting the following strace errors from as and ldd (created as a link
> pointed to libc.so) i have also seen a segfault from a dynamically linked
> ld ar and ccom.
> 
> For this particular strace I compiled musl with binutils-2.24 and
> pcc-20150228 (as well as a previous version) with the configure settigs
> --disable-gcc-wrapper and --target=i486-linux-musl then booted the system
> and called strace as and strace ldd libc.so respectively. The rest of the
> system was compiled with cflags -O0 -march=i486 and ldflags -static
> 

why do you run libc.so in ldd?

strace wont help here, most likely pcc miscompiled something
or your setup is broken in some other way..

> If anyone has a moment to look into it i would greatly appreciate it and i
> will be happy to provide anything else that helps diagnose the issue.
> 
> thanks
> stephen.

Re: segfault in libc.so

[Rich Felker]

On Tue, Mar 03, 2015 at 12:46:40PM +0100, Szabolcs Nagy wrote:
> * stephen Turner <stephen.n.turner@gmail.com> [2015-03-03 01:00:31 -0500]:
> > I am getting the following strace errors from as and ldd (created as a link
> > pointed to libc.so) i have also seen a segfault from a dynamically linked
> > ld ar and ccom.
> > 
> > For this particular strace I compiled musl with binutils-2.24 and
> > pcc-20150228 (as well as a previous version) with the configure settigs
> > --disable-gcc-wrapper and --target=i486-linux-musl then booted the system
> > and called strace as and strace ldd libc.so respectively. The rest of the
> > system was compiled with cflags -O0 -march=i486 and ldflags -static
> > 
> 
> why do you run libc.so in ldd?
> 
> strace wont help here, most likely pcc miscompiled something
> or your setup is broken in some other way..

I agree. I think gdb, not strace, is the right tool here, but
unfortunately the debug info produced by pcc seems to be wrong or
misinterpreted by gdb, making it hard to do anything except
single-stepping, disassembly, and inspecting registers..

Rich

Re: segfault in libc.so

[stephen Turner]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

> I agree. I think gdb, not strace, is the right tool here, but
> unfortunately the debug info produced by pcc seems to be wrong or
> misinterpreted by gdb, making it hard to do anything except
> single-stepping, disassembly, and inspecting registers..
>
> Rich

Thanks Rich, I will look into that tool soon. For the time being I have
been troubleshooting the best way I know how by substituting one part at a
time.

What I know so far is
* the corruption appears to be limited to libc.so only and once a bad
libc.so is replaced with a glibc/gcc built libc.so everything is fine.
* Libc.a gets smaller when compilled by pcc while libc.so gets bigger.
Minute as it may be.
* Everything can be compiled and work dynamic by pcc except libc.so (what
makes it so differant from libc.a and everything else?)
* everything on/before pcc 20150101 returns a visible error when compiling
musl that I dont recall atm but will report tomorrow (back to 20141201
atleast)
* version 20150110 musl compiles (possibly corrupted havent checked) but
make4.0 breaks, again visibly in jobs.o
* version 20150120 everything compiled (but libc.so is corrupt) same for
the latest version.

Your on the pcc list too so im sure you have noticed no response yet. I
read that one person is away, I didnt pay attention to the name but im
guessing one of the main programmers.

So I have shown today that its not a musl issue, though I doubted it was
anyways, no one has reported a corruption issue. But I found these details
that will hopefully help identify the root issue eventually.

Thanks
Stephen

[-- Attachment #2: Type: text/html, Size: 1744 bytes --]

Re: [musl] segfault in libc.so

[stephen Turner]

[-- Attachment #1.1: Type: text/plain, Size: 2633 bytes --]

This is what i have found so far on the libc.so corruption now also known
to involve libfl.so.2. Im copying both musl (for an update) and pcc however
this appears to be a pcc specific bug and this email is mostly for that
purpose.

> What I know so far is
>
> * the corruption appears to be limited to libc.so only and once a bad
> libc.so is replaced with a glibc/gcc built libc.so everything is fine.
>
I have to correct this statement, i have now found a second corrupted lib
after running a few compiles, libfl.so.2 generated by binutils for the use
of atleast the "ar" program

the error however when ar is reported is said to be in libc.so, knowing
better at this point i "ldd ar" and found that lib and when i "ldd
libfl.so.2" i get the output yylex symbol not found.

> * Libc.a gets smaller when compilled by pcc while libc.so gets bigger.
> Minute as it may be.
> * Everything can be compiled and work dynamic by pcc except libc.so (what
> makes it so differant from libc.a and everything else?)
> * everything on/before pcc 20150101 returns a visible error when compiling
> musl that I dont recall atm but will report tomorrow (back to 20141201
> atleast)
>
the error is
error /usr/libexec/ccom terminated with status 1
recipe for target src/complex/catanf.lo faild
compiler error bad STCALL hidden reg
I attached the strace from this process which failed in musl-libc and per
your suggestion Rich im also looking into the use of gdb now as well. Since
this is a older version of pcc (albiet not by much) I wonder if this STCALL
reg could point to the corruption by pcc?


> * version 20150110 musl compiles (possibly corrupted havent checked) but
> make4.0 breaks, again visibly in jobs.o
> * version 20150120 everything compiled (but libc.so is corrupt) same for
> the latest version.
>
> Your on the pcc list too so im sure you have noticed no response yet. I
> read that one person is away, I didnt pay attention to the name but im
> guessing one of the main programmers.
>
> So I have shown today that its not a musl issue, though I doubted it was
> anyways, no one has reported a corruption issue. But I found these details
> that will hopefully help identify the root issue eventually.
>
> Thanks
> Stephen
>
The errors im finding at this point are 2 and 3 generations deep, I build a
static system with gcc/glibc on debian and move everything to a initrd. I
rebuild in this environment to be a dynamic musl-libc create another initrd
and its with this dynamic initrd building my 3rd gen (or second dynamic) i
get my breakage.

Thanks for your time, I hope to hear back from someone about fixing pcc
soon.

Stephen

[-- Attachment #1.2: Type: text/html, Size: 3671 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Pcc mailing list
Pcc@lists.ludd.ltu.se
https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc