----- Original Message -----
> Alex,
> 
> Just for a sanity check, can you try rebuilding without this 7.2.2 patch:
> 
>   commit 11eceac4ef54e9bf7d64ce3c96a7454aeb126fd8
>   Author: Dave Anderson <ander...@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.
>     (ander...@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 a...@hpe.com +1 514-941-8030 Mobile
> > 2344 Boulevard Alfred Nobel, Saint-Laurent, QC, Canada
> > 
> > --
> > Crash-utility mailing list
> > Crash-utility@redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> 
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
> 

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Reply via email to