[Crash-utility] [ANNOUNCE] crash version 7.2.2 is available

[Alex Sidorenko]

> 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 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
>

-- 
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