Bug 1909548

Summary: valgrind thinks shmctl(IPC_STAT) doesn't set shm_nattch on aarch64
Product: [Fedora] Fedora Reporter: Tom Lane <tgl>
Component: valgrindAssignee: Mark Wielaard <mjw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: dodji, jakub, mjw
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Unspecified   
Whiteboard:
Fixed In Version: valgrind-3.16.1-16.fc34 valgrind-3.16.1-18.fc33 valgrind-3.16.1-18.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-03 19:50:46 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:
Embargoed:
Attachments:
Description Flags
shmemtest.c none

Description Tom Lane 2020-12-20 21:32:04 UTC
Created attachment 1740771 [details]
shmemtest.c

Description of problem:
On aarch64, valgrind claims that shmid_ds.shm_nattch is undefined after a successful shmctl(IPC_STAT) operation.  This is wrong (and doesn't happen on x86_64).

Version-Release number of selected component (if applicable):
valgrind-3.16.1-11.fc33.aarch64

How reproducible:
100%

Steps to Reproduce:
1. gcc -Wall -O2 -g shmemtest.c
2. valgrind ./a.out

Actual results:
==81316== Memcheck, a memory error detector
==81316== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==81316== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==81316== Command: ./a.out
==81316== 
==81316== Conditional jump or move depends on uninitialised value(s)
==81316==    at 0x48E3E70: __vfprintf_internal (vfprintf-internal.c:1646)
==81316==    by 0x48D2DDB: printf (printf.c:33)
==81316==    by 0x400683: main (shmemtest.c:32)
==81316== 
==81316== Use of uninitialised value of size 8
==81316==    at 0x48CE040: _itoa_word (_itoa.c:179)
==81316==    by 0x48E3BE7: __vfprintf_internal (vfprintf-internal.c:1646)
==81316==    by 0x48D2DDB: printf (printf.c:33)
==81316==    by 0x400683: main (shmemtest.c:32)
==81316== 
==81316== Conditional jump or move depends on uninitialised value(s)
==81316==    at 0x48CE04C: _itoa_word (_itoa.c:179)
==81316==    by 0x48E3BE7: __vfprintf_internal (vfprintf-internal.c:1646)
==81316==    by 0x48D2DDB: printf (printf.c:33)
==81316==    by 0x400683: main (shmemtest.c:32)
==81316== 
==81316== Conditional jump or move depends on uninitialised value(s)
==81316==    at 0x48E45E4: __vfprintf_internal (vfprintf-internal.c:1646)
==81316==    by 0x48D2DDB: printf (printf.c:33)
==81316==    by 0x400683: main (shmemtest.c:32)
==81316== 
==81316== Conditional jump or move depends on uninitialised value(s)
==81316==    at 0x48E5628: __vfprintf_internal (vfprintf-internal.c:1646)
==81316==    by 0x48D2DDB: printf (printf.c:33)
==81316==    by 0x400683: main (shmemtest.c:32)
==81316== 
shm_nattch = 0
==81316== 

Expected results:
No complaints.

Additional info:
I've not checked whether it thinks that the other fields of struct shmid_ds are defined.  nattch is the only one Postgres cares about ...

Comment 1 Mark Wielaard 2020-12-20 22:00:41 UTC
This is odd, POST(sys_shmctl) in coregrind/m_syswrap/syswrap-linux.c is defined as:

POST(sys_shmctl)
{
#ifdef VGP_amd64_linux
   ML_(generic_POST_sys_shmctl)(tid, RES,ARG1,ARG2|VKI_IPC_64,ARG3);
#else
   ML_(generic_POST_sys_shmctl)(tid, RES,ARG1,ARG2,ARG3);
#endif
}

I don't understand why VKI_IPC_64 is only used for amd64, it seems all 64bit arches should use the bigger struct.
Do you happen to know whether the same fails on ppc64le or s390x?
I'll try to investigate later, don't have access to non-x86-64 arches right now.

Comment 2 Tom Lane 2020-12-20 22:14:45 UTC
(In reply to Mark Wielaard from comment #1)
> I don't understand why VKI_IPC_64 is only used for amd64, it seems all 64bit
> arches should use the bigger struct.
> Do you happen to know whether the same fails on ppc64le or s390x?

Can't help you there.  (I do miss having access to Red Hat's lab hardware.)

Comment 3 Mark Wielaard 2021-01-30 13:24:04 UTC
This looks like upstream bug https://bugs.kde.org/show_bug.cgi?id=410743

Comment 4 Mark Wielaard 2021-02-03 19:50:46 UTC
(In reply to Mark Wielaard from comment #3)
> This looks like upstream bug https://bugs.kde.org/show_bug.cgi?id=410743

It wasn't exactly that, but that did fix a related issue on i386. Added a fix for arm64. And all should be good now.

Comment 5 Fedora Update System 2021-02-15 16:46:56 UTC
FEDORA-2021-df23f1f7db has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-df23f1f7db

Comment 6 Fedora Update System 2021-02-15 16:52:15 UTC
FEDORA-2021-aae6525270 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-aae6525270

Comment 7 Fedora Update System 2021-02-16 01:15:00 UTC
FEDORA-2021-df23f1f7db has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-df23f1f7db`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-df23f1f7db

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2021-02-16 01:18:39 UTC
FEDORA-2021-aae6525270 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-aae6525270`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-aae6525270

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2021-02-18 01:24:04 UTC
FEDORA-2021-df23f1f7db has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2021-02-24 20:44:46 UTC
FEDORA-2021-aae6525270 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.