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@xxxxxxxxxx> > > 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@xxxxxxxxxx) > > > > 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@xxxxxxx +1 514-941-8030 Mobile > > > 2344 Boulevard Alfred Nobel, Saint-Laurent, QC, Canada > > > > > > -- > > > Crash-utility mailing list > > > Crash-utility@xxxxxxxxxx > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- > > Crash-utility mailing list > > Crash-utility@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
