[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

--- Comment #10 from Anton Kirilov  ---
I tried the fix both on Aarch32 and Aarch64, and it worked. I just modified
lines 35-36 of the test program to either:

 __asm__ __volatile__("sub r0, sp, #8192\n\tldr %0, [r0, #0]"
 : "=r"(res) : : "r0", "memory","cc");

for Aarch32, or:

 __asm__ __volatile__("sub x0, sp, #8192\n\tldr %w0, [x0, #0]"
 : "=r"(res) : : "r0", "memory","cc");

for Aarch64.

I also ran a simple test application with ART, and this particular issue
disappeared (although Valgrind complained about other things).

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

--- Comment #6 from Anton Kirilov  ---
Just a theoretical question.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

--- Comment #4 from Anton Kirilov  ---
(In reply to Julian Seward from comment #3)
> An alternative is to introduce a new flag, something like this (eg)
> 
>   --ignore-accesses-below-sp-range=-
> 
> so that just the specified range is ignored.
Yes, that will work as well.

Just a quick idea - do you think it is worth it supporting more than one range
(e.g. for running code generated by a compiler that misbehaves in the same way
as GCC 2.96 in an environment similar to Android)?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360574

--- Comment #4 from Anton Kirilov  ---
I have tested the patch, and it makes the error message disappear.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360574

--- Comment #2 from Anton Kirilov  ---
Yes, I can.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

--- Comment #2 from Anton Kirilov  ---
Yes, that is correct. ART also sets up a signal handler for SIGSEGV.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360574

Anton Kirilov  changed:

   What|Removed |Added

 CC||jacob.bramley+...@arm.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360574] New: Wrong parameter type for an ashmem ioctl() call on Android and ARM64

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360574

Bug ID: 360574
   Summary: Wrong parameter type for an ashmem ioctl() call on
Android and ARM64
   Product: valgrind
   Version: 3.11.0
  Platform: Android
OS: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: memcheck
  Assignee: jsew...@acm.org
  Reporter: anton.kiri...@linaro.org

The ASHMEM_SET_SIZE ioctl() call accepts a size as a parameter, not a pointer,
which is not recognized by Valgrind on ARM64, and results in errors such as:

==2040== Syscall param ioctl(generic) points to unaddressable byte(s)
==2040==at 0x496F768: __ioctl (in /system/lib64/libc.so)
==2040==by 0x492530B: ioctl (in /system/lib64/libc.so)
==2040==by 0x5A9B04B: ashmem_create_region (in /system/lib64/libcutils.so)
==2040==by 0x5768BA3: art::MemMap::MapAnonymous(char const*, unsigned
char*, unsigned long, int, bool, bool, std::__1::basic_string*, bool) (in
/system/lib64/libart.so)
==2040==by 0x5612247: art::gc::Heap::Heap(unsigned long, unsigned long,
unsigned long, unsigned long, double, double, unsigned long, unsigned long,
std::__1::basic_string const&, art::InstructionSet,
art::gc::CollectorType, art::gc::CollectorType,
art::gc::space::LargeObjectSpaceType, unsigned long, unsigned long, unsigned
long, bool, unsigned long, unsigned long, bool, bool, bool, bool, bool, bool,
bool, bool, bool, bool, unsigned long) (in /system/lib64/libart.so)
==2040==by 0x583BCFB: art::Runtime::Init(art::RuntimeArgumentMap&&) (in
/system/lib64/libart.so)
==2040==by 0x583E823:
art::Runtime::Create(std::__1::vector, void const*>,
std::__1::allocator, void const*> > >
const&, bool) (in /system/lib64/libart.so)
==2040==by 0x5705093: JNI_CreateJavaVM (in /system/lib64/libart.so)
==2040==by 0x109377: main (in /system/bin/dalvikvm64)
==2040==  Address 0x1000 is not stack'd, malloc'd or (recently) free'd

I have seen the issue with a build of the master branch of the Android Open
Source Project, but it is reproducible on older versions as well (e.g. the 6.0
release).

Reproducible: Always

Steps to Reproduce:
1. Install the ARM64 version of Valgrind on the Android device as documented in
the README.android file; assume that the installation directory is
/data/local/tmp/valgrind.
2. Get an APK or a DEX file; let its name be Test.dex, and let the name of the
class containing the main() method be Test as well.
3. adb push Test.dex /data/local/tmp
4. adb shell /data/local/tmp/valgrind/bin/valgrind dalvikvm64 -cp
/data/local/tmp/Test.dex Test

Actual Results:  
Errors similar to the one above are displayed.

Expected Results:  
No errors of that type are shown.

Note that Valgrind is not affected by the same issue on a 32-bit ARM platform.

I have been using a suppression rule as a workaround:

{
  ashmem ioctl
  Memcheck:Param
  ioctl(generic)
  ...
  fun:ioctl
  fun:ashmem_create_region
}

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

Anton Kirilov  changed:

   What|Removed |Added

 CC||jacob.bramley+...@arm.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 360571] New: Error about the Android Runtime reading below the stack pointer on ARM

[Anton Kirilov via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

Bug ID: 360571
   Summary: Error about the Android Runtime reading below the
stack pointer on ARM
   Product: valgrind
   Version: 3.11.0
  Platform: Android
OS: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: memcheck
  Assignee: jsew...@acm.org
  Reporter: anton.kiri...@linaro.org

The Android Runtime (ART) uses reads below the stack pointer (combined with a
guard memory region) to detect stack overflow, and as a result when an
application is run in the virtual machine, Valgrind outputs a lot of warnings
such as:

==29768== Invalid read of size 4
==29768==at 0x739AEBE0: ??? (in
/data/dalvik-cache/arm/system@framew...@boot.oat)
==29768==  Address 0xfe96fdb0 is on thread 1's stack
==29768==  8192 bytes below stack pointer
==29768==

The assembly language code that is emitted by ART at the beginning of each
method, and that causes the warning, looks like this:

sub r12, sp, #8192
ldr.w r12, [r12, #0]

The --workaround-gcc296-bugs command-line parameter is supposed to help, but it
has some problems - it forces Valgrind to ignore memory accesses that are up to
1 KB below SP, but on ARM the distance is 8 KB.

I have seen the issue with a build of the master branch of the Android Open
Source Project, but is reproducible on older versions as well (e.g. the 6.0
release).

Reproducible: Always

Steps to Reproduce:
1. Install Valgrind on the Android device as documented in the README.android
file; assume that the installation directory is /data/local/tmp/valgrind.
2. Get an APK or a DEX file; let its name be Test.dex, and let the name of the
class containing the main() method be Test as well.
3. adb push Test.dex /data/local/tmp
4. adb shell /data/local/tmp/valgrind/bin/valgrind --workaround-gcc296-bugs
dalvikvm -cp /data/local/tmp/Test.dex Test

Actual Results:  
Warnings similar to the one above are displayed.

Expected Results:  
No warnings of that type are shown.

Currently, the workaround that I have been using is manually patching the
Valgrind source code (in particular, the VG_GCC296_BUG_STACK_SLOP constant in
memcheck/mc_errors.c), but a better solution is to introduce a way to configure
that value at runtime. Furthermore, I'd like to suggest an addition to the
README.android file - mentioning that people who want to run apps in the
virtual machine with Valgrind should use the --workaround-gcc296-bugs
parameter. Finally, that argument should perhaps be renamed to something more
accurate.

-- 
You are receiving this mail because:
You are watching all bug changes.