https://bugs.kde.org/show_bug.cgi?id=451827
Bug ID: 451827
Summary: [ppc64le] VEX temporary storage exhausted with several
vbpermq instructions
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: jch...@redhat.com
Target Milestone: ---
SUMMARY
Valgrind will fail with "VEX temporary storage exhausted" when running a
ppc64le binary which contains several vbpermq instructions together. The
following C source reproduces the issue:
```
int main(){
asm("vbpermq 6,6,10");
asm("vbpermq 7,7,10");
asm("vbpermq 8,8,10");
// if this doesn't trigger the issue, just copy-paste some asm lines.
return 0;
}
```
Building and running this will produce the following output:
```
# ./vg-in-place ../a.out
==592850== Memcheck, a memory error detector
==592850== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==592850== Using Valgrind-3.19.0.GIT and LibVEX; rerun with -h for copyright
info
==592850== Command: ../a.out
==592850==
VEX temporary storage exhausted.
Pool = TEMP, start 0x598a5528 curr 0x59d5b420 end 0x59d6a067 (size 5000000)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
vex storage: T total 164492400 bytes allocated
vex storage: P total 192 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==592850== at 0x58056FD8: show_sched_status_wrk (m_libcassert.c:406)
==592850== by 0x5805718F: report_and_quit (m_libcassert.c:477)
==592850== by 0x5805740B: panic (m_libcassert.c:553)
==592850== by 0x5805740B: vgPlain_core_panic_at (m_libcassert.c:558)
==592850== by 0x5805745B: vgPlain_core_panic (m_libcassert.c:563)
==592850== by 0x58076D37: failure_exit (m_translate.c:761)
==592850== by 0x581867FB: vpanic (main_util.c:253)
==592850== by 0x581868AB: private_LibVEX_alloc_OOM (main_util.c:181)
==592850== by 0x5827C0C3: LibVEX_Alloc_inline (main_util.h:176)
==592850== by 0x5827C0C3: addHInstr_SLOW (host_generic_regs.c:332)
==592850== by 0x58250F7F: addHInstr (host_generic_regs.h:402)
==592850== by 0x58252B8B: emit_instr (host_generic_reg_alloc3.c:301)
==592850== by 0x58252B8B: doRegisterAllocation_v3
(host_generic_reg_alloc3.c:1320)
==592850== by 0x58183FE3: libvex_BackEnd (main_main.c:1133)
==592850== by 0x58183FE3: LibVEX_Translate (main_main.c:1236)
==592850== by 0x5807A82F: vgPlain_translate (m_translate.c:1831)
==592850== by 0x580CD1FB: handle_tt_miss (scheduler.c:1141)
==592850== by 0x580CD1FB: vgPlain_scheduler (scheduler.c:1503)
==592850== by 0x5812209F: thread_wrapper (syswrap-linux.c:101)
==592850== by 0x5812209F: run_a_thread_NORETURN (syswrap-linux.c:154)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 592850)
==592850== at 0x100005CC: main (in /root/a.out)
client stack range: [0x1FFEFF0000 0x1FFF00FFFF] client SP: 0x1FFF00E740
valgrind stack range: [0x1002DF0000 0x1002EEFFFF] top usage: 15728 of 1048576
```
Originally found in rhel-9 with valgrind 3.18.1, but reproducible in fresh git
build (see https://bugzilla.redhat.com/show_bug.cgi?id=2067187)
I found this similar to this already fixed issue:
https://bugs.kde.org/show_bug.cgi?id=375839
--
You are receiving this mail because:
You are watching all bug changes.
