[Bug ada/89493] New: Stack smashing on armv7hl
pavel at zhukoff dot net
gcc-bugzilla@gcc.gnu.org
Mon Feb 25 14:01:00 GMT 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89493
Bug ID: 89493
Summary: Stack smashing on armv7hl
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: pavel at zhukoff dot net
Target Milestone: ---
Created attachment 45816
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45816&action=edit
reproducer
Reporting this for ada as reproducer is part of gprbuild (gprinstall) code.
In some cases (return from exception handler) stack pointer is set to weird
value and either stack smashing protection or storage error occurs.
it's easy and 100% reproducible in Fedora linux distribution
https://bugzilla.redhat.com/show_bug.cgi?id=1677173
gcc-9.0.1-0.4.fc30.armv7hl
gprbuild-2018-12.fc30.armv7hl
All other architectures (x86, s390x, ppc64le and aarch64 work fine)
We were able to strip reproducer to ~200 LOC (attached)
# gprbuild -v -cargs:Ada -O2 -g
# valgrind ./exe/process
==29563== Memcheck, a memory error detector
==29563== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29563== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==29563== Command: ./exe/process
==29563==
warning: file does not exist '/tmp/a/satrace.log'
==29563== Warning: client switching stacks? SP change: 0xbdef07c0 --> 0x68818
==29563== to suppress, use: --max-stackframe=1108836440 or greater
aaa
==29563== Invalid write of size 4
==29563== at 0x40C04: system__secondary_stack__ss_release (in
/tmp/test/exe/process)
==29563== Address 0x68754 is 12 bytes inside data symbol
"ada_main__sec_default_sized_stacks"
==29563==
==29563== Invalid read of size 4
==29563== at 0x1A09C: _ada_process (process.adb:119)
==29563== Address 0x687ec is 164 bytes inside data symbol
"ada_main__sec_default_sized_stacks"
==29563==
==29563== Invalid read of size 4
==29563== at 0x1A0A4: _ada_process (process.adb:119)
==29563== Address 0xe1a02026 is not stack'd, malloc'd or (recently) free'd
More information about the Gcc-bugs
mailing list