[Crash-utility] [ANNOUNCE] crash version 7.2.2 is available
Dave Anderson
anderson at redhat.com
Thu May 17 14:35:59 UTC 2018
Hi Alex,
Although I still don't understand why it's only reproducible when crash
is built with certain compilers, I guess it has something to do with how
the local variables are laid out on the function's stack?
Thanks for catching this -- I'll release a 7.2.3 version with the fix
later today.
Dave
----- Original Message -----
>
>
> ----- Original Message -----
> > Alex,
> >
> > Just for a sanity check, can you try rebuilding without this 7.2.2 patch:
> >
> > commit 11eceac4ef54e9bf7d64ce3c96a7454aeb126fd8
> > Author: Dave Anderson <anderson at redhat.com>
> > Date: Fri Apr 20 14:37:52 2018 -0400
> >
> > Fixes to address several gcc-8.0.1 compiler warnings that are generated
> > when building with "make warn". The warnings are all false alarm
> > messages of type [-Wformat-overflow=], [-Wformat-truncation=] and
> > [-Wstringop-truncation]; the affected files are extensions.c, task.c,
> > kernel.c, memory.c, remote.c, symbols.c, filesys.c and xen_hyper.c.
> > (anderson at redhat.com)
> >
> > It does modify some buffer sizes used by the mount command.
> >
> > Thanks,
> > Dave
>
> It's this, where the read_string() call into buf4 should be shortened to (BUFSIZE/2)-1:
>
> --- a/filesys.c
> +++ b/filesys.c
> @@ -1366,10 +1366,10 @@ show_mounts(ulong one_vfsmount, int flags, struct
> task_context *namespace_contex
> long s_dirty;
> ulong devp, dirp, sbp, dirty, type, name;
> struct list_data list_data, *ld;
> - char buf1[BUFSIZE];
> + char buf1[BUFSIZE*2];
> char buf2[BUFSIZE];
> char buf3[BUFSIZE];
> - char buf4[BUFSIZE];
> + char buf4[BUFSIZE/2];
> ulong *dentry_list, *dp, *mntlist;
> ulong *vfsmnt;
> char *vfsmount_buf, *super_block_buf, *mount_buf;
> @@ -1494,8 +1494,8 @@ show_mounts(ulong one_vfsmount, int flags, struct
> task_context *namespace_contex
> KVADDR, &name, sizeof(void *),
> "file_system_type name", FAULT_ON_ERROR);
>
> - if (read_string(name, buf1, BUFSIZE-1))
> - sprintf(buf3, "%-6s ", buf1);
> + if (read_string(name, buf4, BUFSIZE-1))
> + sprintf(buf3, "%-6s ", buf4);
> else
> sprintf(buf3, "unknown ");
>
> I can reproduce it on a RHEL6 host, but not with new gcc versions.
>
> Dave
>
>
>
>
>
> >
> >
> > ----- Original Message -----
> > > Well, stepping in GDB line-by-line I can see that we segfault at #1594 in
> > > filesys.c
> > >
> > > 1588 if (!one_vfsmount)
> > > (gdb)
> > > 1589 FREEBUF(mntlist);
> > > (gdb)
> > > 1590 if (VALID_STRUCT(mount))
> > > (gdb)
> > > 1593 FREEBUF(vfsmount_buf);
> > > (gdb)
> > > 1594 FREEBUF(super_block_buf);
> > > (gdb)
> > > 1595 }
> > > (gdb)
> > > 0x0000000000000000 in ?? ()
> > >
> > > That is, there is definitely memory corruption somewhere and 'mount' is
> > > most
> > > probably just a victim.
> > >
> > > Alex
> > >
> > > On 2018-05-17 09:36 AM, Alex Sidorenko wrote:
> > >
> > >
> > > crash> mount
> > > VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
> > > ffff88101c916080 ffff88081c837400 rootfs rootfs /
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x0000000000000000 in ?? ()
> > > (gdb) bt
> > > Python Exception <type 'exceptions.ImportError'> No module named
> > > gdb.frames:
> > > #0 0x0000000000000000 in ?? ()
> > > #1 0x0000000000000000 in ?? ()
> > > --
> > > Alex Sidorenko Expert Technologist
> > > ERT Linux HPE Pointnext asid at hpe.com +1 514-941-8030 Mobile
> > > 2344 Boulevard Alfred Nobel, Saint-Laurent, QC, Canada
> > >
> > > --
> > > Crash-utility mailing list
> > > Crash-utility at redhat.com
> > > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> >
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
More information about the Crash-utility
mailing list