Bug 618360

Summary: valgrind-3.5.0-17.fc13.x86_64 failed to properly handle red-zone
Product: [Fedora] Fedora Reporter: H.J. Lu <hongjiu.lu>
Component: valgrindAssignee: Jakub Jelinek <jakub>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: dodji, jakub
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-27 17:35:52 UTC Type: ---
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
A testcase for Linux/x86-64
none
A smaller testcase none

Description H.J. Lu 2010-07-26 18:40:01 UTC
Created attachment 434491 [details]
A testcase for Linux/x86-64

On x86-64, there is a 128byte red zone. But valgrind-3.5.0-17.fc13.x86_64
failed to handle it properly:

[hjl@gnu-6 valgrind-1]$ make
gcc -O2    foo.c   -o foo
./foo || true
valgrind --tool=memcheck ./foo
==23552== Memcheck, a memory error detector
==23552== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==23552== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==23552== Command: ./foo
==23552== 
==23552== Invalid read of size 8
==23552==    at 0x400548: check_absence_pattern_sets (in /export/home/hjl/bugs/gcc/valgrind-1/foo)
==23552==    by 0x400676: main (in /export/home/hjl/bugs/gcc/valgrind-1/foo)
==23552==  Address 0x1c is not stack'd, malloc'd or (recently) free'd
==23552== 
==23552== 
==23552== Process terminating with default action of signal 11 (SIGSEGV)
==23552==  Access not within mapped region at address 0x1C
==23552==    at 0x400548: check_absence_pattern_sets (in /export/home/hjl/bugs/gcc/valgrind-1/foo)
==23552==    by 0x400676: main (in /export/home/hjl/bugs/gcc/valgrind-1/foo)
==23552==  If you believe this happened as a result of a stack
==23552==  overflow in your program's main thread (unlikely but
==23552==  possible), you can try to increase the size of the
==23552==  main thread stack using the --main-stacksize= flag.
==23552==  The main thread stack size used in this run was 8388608.
==23552== 
==23552== HEAP SUMMARY:
==23552==     in use at exit: 96 bytes in 2 blocks
==23552==   total heap usage: 2 allocs, 0 frees, 96 bytes allocated
==23552== 
==23552== LEAK SUMMARY:
==23552==    definitely lost: 0 bytes in 0 blocks
==23552==    indirectly lost: 0 bytes in 0 blocks
==23552==      possibly lost: 0 bytes in 0 blocks
==23552==    still reachable: 96 bytes in 2 blocks
==23552==         suppressed: 0 bytes in 0 blocks
==23552== Rerun with --leak-check=full to see details of leaked memory
==23552== 
==23552== For counts of detected and suppressed errors, rerun with: -v
==23552== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
make: *** [all] Segmentation fault
[hjl@gnu-6 valgrind-1]$

Comment 1 H.J. Lu 2010-07-27 17:00:00 UTC
Valgrind will touch (%RSP - 8). If (%RSP - 8) is used for spill,
we will get the wrong value when it is restored.

Comment 2 Jakub Jelinek 2010-07-27 17:35:52 UTC
Please continue in the upstream bug.

Comment 3 H.J. Lu 2010-07-27 18:53:53 UTC
Created attachment 434800 [details]
A smaller testcase

Here is a smaller testcase which doesn't require libc. I also
fixed a bug in the original testcase.