Re: Valgrind's wine_cp_wcstombs warnings

[Dan Kegel]

Hi Joerg,
did you try the --track-origins option?  That can sometimes give more detail
(see e.g. the traces in this old message):

On Thu, Jul 31, 2008 at 10:14 AM, Dan Kegel  wrote:
> Hi Colin,
> your change
> http://source.winehq.org/git/wine.git/?a=commitdiff;h=c2c1a55f1c08f35ae02b81...
> seems to have triggered some valgrind warnings,
> http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-kernel32_codepage-di...
> e.g.
> -
>
> Use of uninitialised value of size 4
> -
>
> at  wcstombs_sbcs (wctomb.c:186)
> -
>
> by  wine_cp_wcstombs (wctomb.c:457)
> -
>
> by  WideCharToMultiByte (locale.c:1936)
> -
>
> by  test_string_conversion (codepage.c:288)
> -
>
> by  func_codepage (codepage.c:351)
> -
>
> by  run_test (test.h:488)
> -
>
> by  main (test.h:537)
> -
>
> Uninitialised value was created by a stack allocation
> -
>
> at  test_string_conversion (codepage.c:216)
> -
>
> Use of uninitialised value of size 4
> -
>
> at  wcstombs_sbcs_slow (wctomb.c:246)
> -
>
> by  wine_cp_wcstombs (wctomb.c:453)
> -
>
> by  WideCharToMultiByte (locale.c:1936)
> -
>
> by  test_string_conversion (codepage.c:288)
> -
>
> by  func_codepage (codepage.c:352)
> -
>
> by  run_test (test.h:488)
> -
>
> by  main (test.h:537)
> -
>
> Uninitialised value was created by a stack allocation
> -
>
> at  test_string_conversion (codepage.c:216)
>
> Could you have a look?

Valgrind's wine_cp_wcstombs warnings

Hi,

Dan Kegel wrote:
> did you try the --track-origins option?

That looks like an exact fit, thank you.

Well, this option is not present in Ubuntu Intrepid's Valgrind.
In Ubuntu Lucid, the option is present but Valgrind does not
 complain about wine_cp_wcstombs there.
I conclude it was likely a false alarm due to a bug in old Valgrind.

Regards,
 Jörg Höhle

Valgrind memory leaks in winmm + mciwave

Hi,

By mistake, I ran Valgrind in Ubuntu Lucid (prerelease) upon an old
version of Wine (1.1.35) that does not perform as much WINMM tests as
nowadays.  Yet that old version reveals several memory leaks still
present, one of them shown below in MMIO, repeated for every failing
MMIO_Open(no_such_file).  The 8KB buffer is then lost (log below).
One is in mciwave, others in winmm/mci.c.  They are not false alarms.

Why did I never see winmm/mci in Dan Kegel's Valgrind logs?
Looking at the wrong place? E.g. nothing in
http://kegel.com/wine/valgrind/logs/2010-03-18-21.54/

BTW, Valgrind with Wine is currently in a sad state:

Why does Valgrind with 1.1.43 insist on updating .wine with every run?
VALGRIND_OPTS="--trace-children=yes --log-file=/dev/shm/v%p.log --leak-check=full --malloc-fill=A5 --free-fill=DE --track-origins=yes" WINETEST_WRAPPER=valgrind make mci.ok

What crashes while doing so, causing an infinite loop by crashing
winedbg, causing yet another winedbg to be started, crashing and
causing yet another winedbg...?   Wine should prevent this loop.
The main process (running the tests) nevertheless runs!

What commit made Valgrind loose its ability to correctly report
backtraces? The same one that broke winedbg's "bt all" command?

Backtraces were fine in wine-1.1.35:
==4521== 8,192 bytes in 1 blocks are definitely lost in loss record 597 of 612
==4521==  RtlAllocateHeap (heap.c:1423)
==4521==  MMIO_SetBuffer (mmio.c:561)
==4521==  MMIO_Open (mmio.c:653)
==4521==  mmioOpenW (mmio.c:697)
==4521==  WAVE_mciOpenFile (mciwave.c:473)
==4521==  MCIWAVE_DriverProc (mciwave.c:551)
==4521==  SendDriverMessage (driver.c:136)
==4521==  MCI_SendCommandFrom32 (mci.c:903)
==4521==  MCI_FinishOpen (mci.c:926)
==4521==  mciSendStringW (mci.c:1393)
==4521==  mciSendStringA (mci.c:1432)
==4521==  test_openCloseWAVE (mci.c:217)

With 1.1.43+git as of 2010-05-01
==4325== 8,192 bytes in 1 blocks are definitely lost in loss record 648 of 660
==4325==  RtlAllocateHeap (heap.c:254)
==4325==  MMIO_SetBuffer (mmio.c:561)
==4325==  MMIO_Open (mmio.c:654)
==4325==  mmioOpenW (mmio.c:703)
==4325==  ??? (in /.../dlls/winealsa.drv/winealsa.drv.so)
==4325==  ??? (in /.../dlls/winealsa.drv/winealsa.drv.so)
==4325==  SendDriverMessage (driver.c:136)
==4325==  MCI_SendCommandFrom32 (mci.c:892)
==4325==  MCI_FinishOpen (mci.c:915)
==4325==  mciSendStringW (mci.c:1416)
==4325==  mciSendStringA (mci.c:1455)
==4325==  test_openCloseWAVE (mci.c:271)

Regards,
 Jörg Höhle

Valgrind memory leaks in winmm + mciwave

[Dan Kegel]

On Fri, May 7, 2010 at 5:07 AM,   wrote:
> Why did I never see winmm/mci in Dan Kegel's Valgrind logs?

You've just run into http://bugs.winehq.org/show_bug.cgi?id=20919

See http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-dail...
...
# Disable any tests known to hang reliably
# http://bugs.winehq.org/show_bug.cgi?id=20919
touch dlls/kernel32/tests/process.ok
touch dlls/ole32/tests/marshal.ok
touch dlls/shdocvw/tests/webbrowser.ok
touch dlls/urlmon/tests/url.ok
touch dlls/winmm/tests/mci.ok
touch dlls/winmm/tests/wave.ok

It would be good to get those cleaned up.

(Stack frames like
==4325==  ??? (in /.../dlls/winealsa.drv/winealsa.drv.so)
probably mean that the dll has been unloaded before the stack frame was
printed.)
- Dan