Bug 420780 - PPCle erroneous report on strncmp use.
Summary: PPCle erroneous report on strncmp use.
Status: REOPENED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.15 SVN
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-30 01:23 UTC by Rusty Russell
Modified: 2021-10-07 03:04 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rusty Russell 2020-04-30 01:23:26 UTC
SUMMARY

Both valgrind 3.15 and git (60a7ebedc0b53e2cdcea112635a285d8136b68a8) report an error. This seems similar to https://bugs.kde.org/show_bug.cgi?id=386945

Reduced from a real test cast at https://github.com/ElementsProject/lightning/issues/3672

/* Compile with -O3 */
#include <string.h>
#include <stdint.h>

int main(int argc, char *argv[])
{
	char *s = strdup("02aaa2010000000");

	for (size_t i = 0; i < strlen(s); i++) {
		if (!strncmp(s + i, " * ", 3))
			return 1;
	}
	return 0;
}


STEPS TO REPRODUCE
1. Enter the above trivial program, and compile with -O3.
2. Run valgrind ./test-valgrind


OBSERVED RESULT

==12951== Memcheck, a memory error detector
==12951== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12951== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==12951== Command: ./test-valgrind
==12951== 
==12951== Invalid read of size 4
==12951==    at 0x180774: main (in /home/rusty/test-valgrind)
==12951==  Address 0x4b1004d is 13 bytes inside a block of size 16 alloc'd
==12951==    at 0x48942AC: malloc (vg_replace_malloc.c:307)
==12951==    by 0x499C5E3: strdup (strdup.c:42)
==12951==    by 0x18071B: main (in /home/rusty/test-valgrind)
==12951== 
==12951== 
==12951== HEAP SUMMARY:
==12951==     in use at exit: 16 bytes in 1 blocks
==12951==   total heap usage: 1 allocs, 0 frees, 16 bytes allocated
==12951== 
==12951== LEAK SUMMARY:
==12951==    definitely lost: 16 bytes in 1 blocks
==12951==    indirectly lost: 0 bytes in 0 blocks
==12951==      possibly lost: 0 bytes in 0 blocks
==12951==    still reachable: 0 bytes in 0 blocks
==12951==         suppressed: 0 bytes in 0 blocks
==12951== Rerun with --leak-check=full to see details of leaked memory
==12951== 
==12951== For lists of detected and suppressed errors, rerun with: -s
==12951== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)




EXPECTED RESULT

No error (except the memleak, sure).

SOFTWARE/OS VERSIONS

Linux falco.openpower.xyz 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:13 UTC 2020 ppc64le ppc64le ppc64le GNU/Linux

libc6 version: 2.27-3ubuntu1

ADDITIONAL INFORMATION

Here's the assembler from gcc -S:

	.file	"test-valgrind.c"
	.abiversion 2
	.section	".text"
	.globl strncmp
	.section	.text.startup,"ax",@progbits
	.align 2
	.p2align 4,,15
	.globl main
	.type	main, @function
main:
.LCF0:
0:	addis 2,12,.TOC.-.LCF0@ha
	addi 2,2,.TOC.-.LCF0@l
	.localentry	main,.-main
	mflr 0
	std 28,-32(1)
	std 29,-24(1)
	addis 3,2,.LC0@toc@ha
	std 30,-16(1)
	std 31,-8(1)
	addi 3,3,.LC0@toc@l
	addis 30,2,.LC1@toc@ha
	addi 30,30,.LC1@toc@l
	li 28,0
	std 0,16(1)
	stdu 1,-64(1)
	bl strdup
	nop
	mr 31,3
	bl strlen
	nop
	add 29,31,3
	b .L2
	.p2align 4,,15
.L17:
	bl strncmp
	nop
.L4:
	cmpwi 7,3,0
	addi 31,31,1
	beq 7,.L9
.L2:
	cmpld 5,31,29
	rldicl 9,31,0,52
	cmpdi 7,9,4092
	li 5,3
	mr 4,30
	mr 3,31
	beq 5,.L16
	bge 7,.L17
	lwbrx 9,0,31
	lwbrx 10,0,30
	rldicr 9,9,32,23
	rldicr 10,10,32,23
	subf. 3,10,9
	cmpb 8,9,10
	cmpb 7,9,28
	orc 8,7,8
	cntlzd 8,8
	beq 0,.L4
	addi 8,8,8
	addi 31,31,1
	rldcl 3,9,8,56
	rldcl 10,10,8,56
	subf 3,10,3
	cmpwi 7,3,0
	bne 7,.L2
.L9:
	li 3,1
	b .L7
.L16:
	li 3,0
.L7:
	addi 1,1,64
	ld 0,16(1)
	ld 28,-32(1)
	ld 29,-24(1)
	ld 30,-16(1)
	ld 31,-8(1)
	mtlr 0
	blr
	.long 0
	.byte 0,0,0,1,128,4,0,0
	.size	main,.-main
	.section	.rodata.str1.8,"aMS",@progbits,1
	.align 3
.LC0:
	.string	"02aaa2010000000"
.LC1:
	.string	" * "
	.ident	"GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0"
	.section	.note.GNU-stack,"",@progbits
Comment 1 Rusty Russell 2020-04-30 01:49:17 UTC
Michael Ellerman reports that gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) needsa "-Og" to reproduce this (though of course, the asm works).

He also produced a fix, but he's unsure if it's correct:

https://gist.github.com/mpe/fcb6aa57af7db43f27721bb52f4410ac
Comment 2 Carl Love 2021-10-01 21:38:49 UTC
Compiled the included test case and ran on the current upstream Valgrind as of 9/1/2021.  The test case seems to run fine now.

valgrind ./valgrind-420780
==2869120== Memcheck, a memory error detector
==2869120== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2869120== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info
==2869120== Command: ./valgrind-420780
==2869120== 
==2869120== 
==2869120== HEAP SUMMARY:
==2869120==     in use at exit: 16 bytes in 1 blocks
==2869120==   total heap usage: 1 allocs, 0 frees, 16 bytes allocated
==2869120== 
==2869120== LEAK SUMMARY:
==2869120==    definitely lost: 16 bytes in 1 blocks
==2869120==    indirectly lost: 0 bytes in 0 blocks
==2869120==      possibly lost: 0 bytes in 0 blocks
==2869120==    still reachable: 0 bytes in 0 blocks
==2869120==         suppressed: 0 bytes in 0 blocks
==2869120== Rerun with --leak-check=full to see details of leaked memory
==2869120== 
==2869120== For lists of detected and suppressed errors, rerun with: -s
==2869120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0

Compiled the test case wth

gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0


Marking the issue resolved.
Comment 3 Carl Love 2021-10-01 21:40:23 UTC
Rusty Russell, please verify that the issue is fixed with the current upstream Valgrind source tree.  If so, please close the issue.  If not, please let us know so we can look into it some more.  Thanks.
Comment 4 Rusty Russell 2021-10-07 03:04:46 UTC
Reopened.  Apparently still triggered on valgrind master.

With recent gcc's you need to compile with -Og to reproduce (not -O3).  Or try the asm directly?