https://bugs.kde.org/show_bug.cgi?id=253657
--- Comment #24 from Austin English <austinengl...@gmail.com> ---
(In reply to Daniel Lehman from comment #23)
> > 0030:err:seh:NtRaiseException Unhandled exception code c000001d flags 0
> > addr 0x7bc95b63
>
> that's probably the iretq instruction from set_cpu_context
>
> > What VALGRIND_OPTS are you using?
>
> -v --trace-children=yes --error-limit=no --log-file=output.txt
> --leak-check=full --leak-resolution=high --show-leak-kinds=all
>
> > did I miss a step?
>
> no, sorry, i forgot that i had to create a symlink to find the pdb:
> ln -s $HOME $WINEPREFIX/drive_Y
> because the baked-in path is Y:/stuff/leakage
That's weird..when first trying this, I missed your 'drive_Y' bit and was
symlinking to dosdevices/y:, which failed. With drive_Y, it works (not
valgrind's problem, of course).
I can verify that works for me:
+ /home/austin/src/valgrind/vg-in-place wine64 leakage.exe
preloader: Warning: failed to reserve range 0000000000110000-0000000068000000
==32694== Conditional jump or move depends on uninitialised value(s)
==32694== at 0x14005F7DE: __strncnt (strncnt.cpp:21)
==32694== by 0x7B9D4E0A8F2C: ???
==32694== Uninitialised value was created by a stack allocation
==32694== at 0x14004BB17: setSBUpLow (in
/tmp/tmp.sYSJGwj3qz/stuff/leakage/leakage.exe)
==32694==
00007FFFFE018520
setframe: 00007FFFFE20FCD0
00007FFFFE01C6D0
006e:fixme:kernelbase:AppPolicyGetProcessTerminationMethod 0xfffffffffffffffa,
0x7ffffe20fd10
==32694== 12,345 bytes in 1 blocks are definitely lost in loss record 92 of 93
==32694== at 0x7BC5BB35: initialize_block (heap.c:238)
==32694== by 0x7BC5BB35: RtlAllocateHeap (???:0)
==32694== by 0x140006BDA: a (leakage.c:9)
==32694== by 0x140006BF8: b (leakage.c:14)
==32694== by 0x140006C18: c (leakage.c:19)
==32694== by 0x140006CF8: main (leakage.c:43)
==32694==
==32694== 23,456 bytes in 1 blocks are definitely lost in loss record 93 of 93
==32694== at 0x7BC5BB35: initialize_block (heap.c:238)
==32694== by 0x7BC5BB35: RtlAllocateHeap (???:0)
==32694== by 0x140006C8C: setframe (leakage.c:28)
==32694== by 0x140006CB8: d (leakage.c:33)
==32694== by 0x140006CD8: e (leakage.c:38)
==32694== by 0x140006D0C: main (leakage.c:44)
==32694==
==================================================
For our valgrind friends, if you'd like to test Daniel's patch, here's a short
script to do so. Get wine64 from your package manager (4.0 stable should work,
or probably any version), then run the script, no special wine knowledge needed
:)
#!/bin/bash
# Requires wine64 (nothing special needed, get it from your package manager)
# and valgrind, of course
export VALGRIND="${VALGRIND:-valgrind}"
export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes
--leak-check=full --num-callers=20
--vex-iropt-register-updates=allregs-at-mem-access"
export WINEPREFIX="${WINEPREFIX:-$HOME/.wine}"
tmpdir="$(mktemp -d)"
cd "$tmpdir"
mkdir -p stuff/leakage
cd stuff/leakage
wget -O stuff.tar.bz2 "https://bugs.kde.org/attachment.cgi?id=118764";
tar xjf stuff.tar.bz2
ln -sf "$tmpdir" "$WINEPREFIX/drive_Y"
# Here we go:
"$VALGRIND" wine64 leakage.exe
cd
rm -rf "$tmpdir"
--
You are receiving this mail because:
You are watching all bug changes.
