Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1517296

Summary: wipefs: Invalid write of size 8
Product: Red Hat Enterprise Linux 7 Reporter: Karel Volný <kvolny>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED CURRENTRELEASE QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5-AltCC: ashankar, codonell, fweimer, kvolny, mnewsome, pfrankli
Target Milestone: rc   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-11 14:56:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
full valgrind output none

Description Karel Volný 2017-11-24 14:17:38 UTC
Created attachment 1358680 [details]
full valgrind output

Filed from caserun https://tcms.engineering.redhat.com/run/321358/#caserun_16541329

Version-Release number of selected component (if applicable):
util-linux-2.23.2-48.el7.aarch64

Steps to Reproduce: 
run the test

Actual results: 
...
==5682== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 15 from 9)

Expected results:
(no errors)

see also bug 604875

Comment 2 Karel Zak 2017-11-27 10:40:29 UTC
I think we don't need gziped attachments for plain text :-)

==5682== Memcheck, a memory error detector
==5682== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5682== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==5682== Command: wipefs disk.img
==5682== 
==5682== Invalid write of size 8
==5682==    at 0x496D5B8: _nl_load_locale_from_archive (in /usr/lib64/libc-2.17.so)
==5682==    by 0x496C7BB: _nl_find_locale (in /usr/lib64/libc-2.17.so)
==5682==    by 0x496C0E3: setlocale (in /usr/lib64/libc-2.17.so)
==5682==    by 0x401DEF: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4961533: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00e778 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
==5682== Invalid write of size 8
==5682==    at 0x496FCEC: __dcigettext (in /usr/lib64/libc-2.17.so)
==5682==    by 0x40297B: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4024E3: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4961533: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00e8c8 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
==5682== Invalid write of size 8
==5682==    at 0x496FF5C: __dcigettext (in /usr/lib64/libc-2.17.so)
==5682==    by 0x40297B: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4024E3: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4961533: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00e898 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
==5682== Invalid write of size 8
==5682==    at 0x496FFDC: __dcigettext (in /usr/lib64/libc-2.17.so)
==5682==    by 0x40297B: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4024E3: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4961533: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00e878 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
==5682== Invalid write of size 8
==5682==    at 0x4971E54: read_alias_file (in /usr/lib64/libc-2.17.so)
==5682==    by 0x497238B: _nl_expand_alias (in /usr/lib64/libc-2.17.so)
==5682==    by 0x49706E3: _nl_find_domain (in /usr/lib64/libc-2.17.so)
==5682==    by 0x497003B: __dcigettext (in /usr/lib64/libc-2.17.so)
==5682==    by 0x40297B: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4024E3: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4961533: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00e4f8 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
==5682== Invalid write of size 8
==5682==    at 0x4977A78: qsort_r (in /usr/lib64/libc-2.17.so)
==5682==    by 0x497220B: read_alias_file (in /usr/lib64/libc-2.17.so)
==5682==    by 0x497238B: _nl_expand_alias (in /usr/lib64/libc-2.17.so)
==5682==    by 0x49706E3: _nl_find_domain (in /usr/lib64/libc-2.17.so)
==5682==    by 0x497003B: __dcigettext (in /usr/lib64/libc-2.17.so)
==5682==    by 0x40297B: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4024E3: ??? (in /usr/sbin/wipefs)
==5682==    by 0x4961533: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00e158 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
offset               type
----------------------------------------------------------------
0x438                ext4   [filesystem]
                     UUID:  e8577b15-acac-4015-9243-66b39b3ccf0e

==5682== Invalid write of size 8
==5682==    at 0x400E784: _dl_fini (in /usr/lib64/ld-2.17.so)
==5682==    by 0x4978613: __run_exit_handlers (in /usr/lib64/libc-2.17.so)
==5682==    by 0x497863B: exit (in /usr/lib64/libc-2.17.so)
==5682==    by 0x4961537: (below main) (in /usr/lib64/libc-2.17.so)
==5682==  Address 0x1fff00eb88 is on thread 1's stack
==5682==  8 bytes below stack pointer
==5682== 
==5682== 
==5682== HEAP SUMMARY:
==5682==     in use at exit: 0 bytes in 0 blocks
==5682==   total heap usage: 112 allocs, 112 frees, 46,255 bytes allocated
==5682== 
==5682== All heap blocks were freed -- no leaks are possible
==5682== 
==5682== For counts of detected and suppressed errors, rerun with: -v
==5682== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 15 from 9)


I'd would be nice to have simple reproducer ("wipefs <what>").

Comment 3 Karel Zak 2017-11-27 11:57:55 UTC
Not sure, but it seems like gettext/setlocale issue.

Comment 4 Florian Weimer 2017-11-27 12:06:22 UTC
This was a gcc bug on aarch64.  We have already rebuilt glibc with a fixed gcc.  Please try again with glibc-2.17-219.el7 or later.

Comment 5 Carlos O'Donell 2017-11-27 23:08:16 UTC
Karel,

Have you had a chance to retry with a newer glibc?

Comment 6 Florian Weimer 2017-12-04 18:31:55 UTC
Reassigning back to util-linux for retesting.

Comment 8 Karel Volný 2017-12-06 13:50:00 UTC
with glibc-2.17-220.el7.aarch64
it passes:
https://tcms.engineering.redhat.com/run/321841/#caserun_16586532

- I guess this can be closed as duplicate of the gcc issue mentioned in comment #4

Comment 9 Karel Zak 2017-12-11 14:56:51 UTC
I think we can close this gcc/glibc issue (fixed by glibc-2.17-219.el7).