Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1909548 - valgrind thinks shmctl(IPC_STAT) doesn't set shm_nattch on aarch64
Summary: valgrind thinks shmctl(IPC_STAT) doesn't set shm_nattch on aarch64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: valgrind
Version: 33
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mark Wielaard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-20 21:32 UTC by Tom Lane
Modified: 2021-02-24 20:44 UTC (History)
3 users (show)

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:
Clone Of:
Environment:
Last Closed: 2021-02-03 19:50:46 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
shmemtest.c (842 bytes, text/x-csrc)
2020-12-20 21:32 UTC, Tom Lane 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 410743 0 NOR RESOLVED shmat() calls for 32-bit programs fail when running in 64-bit valgrind 2021-02-12 19:50:35 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.