I can reproduce it on a RHEL6 host, but not with new gcc versions.
Yes, using a different version of GCC/GLIBC can reveal/hide bugs due to slightly different memory layout - I saw this several times.
Alex
On 2018-05-17 10:17 AM, Dave Anderson wrote:
----- 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
--
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
