re: Nate Gallaher : msi: Add tablename tracking to VIEW_find_column

[Dan Kegel-2]

Hi Nate,
your patch seems to have caused new valgrind warnings, could you have a look?

Found via
  http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/diff-msi_db.txt
Details at
  http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/vg-msi_db.txt

 Conditional jump or move depends on uninitialised value(s)
    at  RtlFreeHeap (heap.c:1460)
    by  msi_free (msipriv.h:1099)
    by  VIEW_find_column (msiquery.c:82)
    by  SELECT_AddColumn (select.c:392)
    by  SELECT_CreateView (select.c:436)
    by  INSERT_CreateView (insert.c:393)
    by  sql_parse (sql.y:149)
    by  MSI_ParseSQL (sql.y:960)
    by  MSI_DatabaseOpenViewW (msiquery.c:137)
    by  MsiDatabaseOpenViewW (msiquery.c:279)
    by  MsiDatabaseOpenViewA (msiquery.c:110)
    by  test_streamtable (db.c:1443)
    by  func_db (db.c:8546)
    by  run_test (test.h:535)
    by  main (test.h:585)
  Uninitialised value was created by a stack allocation
    at  VIEW_find_column (msiquery.c:60)
...
 2 bytes in 1 blocks are definitely lost
    at  notify_alloc (heap.c:214)
    by  RtlAllocateHeap (heap.c:1421)
    by  msi_alloc_zero (msipriv.h:1082)
    by  table_create_new_row (table.c:1504)
    by  TABLE_insert_row (table.c:1712)
    by  TABLE_modify (table.c:1860)
    by  MSI_ViewModify (msiquery.c:623)
    by  MsiViewModify (msiquery.c:644)
    by  test_viewmodify_delete_temporary (db.c:5892)
    by  func_db (db.c:8570)
    by  run_test (test.h:535)
    by  main (test.h:585)
...
 4 bytes in 1 blocks are definitely lost
    at  notify_alloc (heap.c:214)
    by  RtlAllocateHeap (heap.c:1421)
    by  msi_alloc (msipriv.h:1076)
    by  strdupW (msipriv.h:1132)
    by  msi_create_table (table.c:664)
    by  CREATE_execute (create.c:72)
    by  MSI_ViewExecute (msiquery.c:462)
    by  MsiViewExecute (msiquery.c:488)
    by  run_query (db.c:177)
    by  test_droptable (db.c:7073)
    by  func_db (db.c:8580)
    by  run_test (test.h:535)
    by  main (test.h:585)
...
 4 bytes in 1 blocks are definitely lost
    at  notify_alloc (heap.c:214)
    by  RtlAllocateHeap (heap.c:1421)
    by  msi_alloc (msipriv.h:1076)
    by  strdupW (msipriv.h:1132)
    by  msi_makestring (table.c:943)
    by  get_tablecolumns (table.c:1016)
    by  table_get_column_info (table.c:608)
    by  msi_update_table_columns (table.c:1053)
    by  TABLE_remove_column (table.c:2040)
    by  TABLE_drop (table.c:2293)
    by  DROP_execute (drop.c:60)
    by  MSI_ViewExecute (msiquery.c:462)
    by  MsiViewExecute (msiquery.c:488)
    by  run_query (db.c:177)
    by  test_dbmerge (db.c:7408)
    by  func_db (db.c:8581)
    by  run_test (test.h:535)
    by  main (test.h:585)
...
 224 bytes in 28 blocks are definitely lost
    at  notify_alloc (heap.c:214)
    by  RtlAllocateHeap (heap.c:1421)
    by  msi_alloc (msipriv.h:1076)
    by  strdupW (msipriv.h:1132)
    by  msi_makestring (table.c:943)
    by  get_tablecolumns (table.c:1014)
    by  table_get_column_info (table.c:608)
    by  msi_update_table_columns (table.c:1053)
    by  TABLE_remove_column (table.c:2040)
    by  TABLE_drop (table.c:2293)
    by  DROP_execute (drop.c:60)
    by  MSI_ViewExecute (msiquery.c:462)
    by  MsiViewExecute (msiquery.c:488)
    by  run_query (db.c:177)
    by  test_dbmerge (db.c:7385)
    by  func_db (db.c:8581)
    by  run_test (test.h:535)
    by  main (test.h:585)k

It also fails here:

db.c:5260: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0
db.c:5336: Test failed: Expected 4, got 8
db.c:5337: Test failed: Unexpected data
db.c:5352: Test failed: Unexpected data
db.c:5378: Test failed: Expected 64, got 68
db.c:5379: Test failed: Unexpected data
db.c:6993: Test failed: Expected "", got "grape"
db.c:6994: Test failed: Expected 0, got 5
db.c:7052: Test failed: Expected "", got "grape"
db.c:7053: Test failed: Expected 0, got 5

[Nathan Gallaher]

Could someone give me a pointer as to how you reproduce this trace?  I've
spent some time fiddling with valgrind, the WINETEST_WRAPPER env var, and
--enable-maintainer-mode, all to no avail.

~Nate

On Wed, 28 Oct 2009, Dan Kegel wrote:

> Hi Nate,
> your patch seems to have caused new valgrind warnings, could you have a look?
>
> Found via
>  http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/diff-msi_db.txt
> Details at
>  http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/vg-msi_db.txt
>
> Conditional jump or move depends on uninitialised value(s)
>    at  RtlFreeHeap (heap.c:1460)
>    by  msi_free (msipriv.h:1099)
>    by  VIEW_find_column (msiquery.c:82)
>    by  SELECT_AddColumn (select.c:392)
>    by  SELECT_CreateView (select.c:436)
>    by  INSERT_CreateView (insert.c:393)
>    by  sql_parse (sql.y:149)
>    by  MSI_ParseSQL (sql.y:960)
>    by  MSI_DatabaseOpenViewW (msiquery.c:137)
>    by  MsiDatabaseOpenViewW (msiquery.c:279)
>    by  MsiDatabaseOpenViewA (msiquery.c:110)
>    by  test_streamtable (db.c:1443)
>    by  func_db (db.c:8546)
>    by  run_test (test.h:535)
>    by  main (test.h:585)
>  Uninitialised value was created by a stack allocation
>    at  VIEW_find_column (msiquery.c:60)
> ...
> 2 bytes in 1 blocks are definitely lost
>    at  notify_alloc (heap.c:214)
>    by  RtlAllocateHeap (heap.c:1421)
>    by  msi_alloc_zero (msipriv.h:1082)
>    by  table_create_new_row (table.c:1504)
>    by  TABLE_insert_row (table.c:1712)
>    by  TABLE_modify (table.c:1860)
>    by  MSI_ViewModify (msiquery.c:623)
>    by  MsiViewModify (msiquery.c:644)
>    by  test_viewmodify_delete_temporary (db.c:5892)
>    by  func_db (db.c:8570)
>    by  run_test (test.h:535)
>    by  main (test.h:585)
> ...
> 4 bytes in 1 blocks are definitely lost
>    at  notify_alloc (heap.c:214)
>    by  RtlAllocateHeap (heap.c:1421)
>    by  msi_alloc (msipriv.h:1076)
>    by  strdupW (msipriv.h:1132)
>    by  msi_create_table (table.c:664)
>    by  CREATE_execute (create.c:72)
>    by  MSI_ViewExecute (msiquery.c:462)
>    by  MsiViewExecute (msiquery.c:488)
>    by  run_query (db.c:177)
>    by  test_droptable (db.c:7073)
>    by  func_db (db.c:8580)
>    by  run_test (test.h:535)
>    by  main (test.h:585)
> ...
> 4 bytes in 1 blocks are definitely lost
>    at  notify_alloc (heap.c:214)
>    by  RtlAllocateHeap (heap.c:1421)
>    by  msi_alloc (msipriv.h:1076)
>    by  strdupW (msipriv.h:1132)
>    by  msi_makestring (table.c:943)
>    by  get_tablecolumns (table.c:1016)
>    by  table_get_column_info (table.c:608)
>    by  msi_update_table_columns (table.c:1053)
>    by  TABLE_remove_column (table.c:2040)
>    by  TABLE_drop (table.c:2293)
>    by  DROP_execute (drop.c:60)
>    by  MSI_ViewExecute (msiquery.c:462)
>    by  MsiViewExecute (msiquery.c:488)
>    by  run_query (db.c:177)
>    by  test_dbmerge (db.c:7408)
>    by  func_db (db.c:8581)
>    by  run_test (test.h:535)
>    by  main (test.h:585)
> ...
> 224 bytes in 28 blocks are definitely lost
>    at  notify_alloc (heap.c:214)
>    by  RtlAllocateHeap (heap.c:1421)
>    by  msi_alloc (msipriv.h:1076)
>    by  strdupW (msipriv.h:1132)
>    by  msi_makestring (table.c:943)
>    by  get_tablecolumns (table.c:1014)
>    by  table_get_column_info (table.c:608)
>    by  msi_update_table_columns (table.c:1053)
>    by  TABLE_remove_column (table.c:2040)
>    by  TABLE_drop (table.c:2293)
>    by  DROP_execute (drop.c:60)
>    by  MSI_ViewExecute (msiquery.c:462)
>    by  MsiViewExecute (msiquery.c:488)
>    by  run_query (db.c:177)
>    by  test_dbmerge (db.c:7385)
>    by  func_db (db.c:8581)
>    by  run_test (test.h:535)
>    by  main (test.h:585)k
>
> It also fails here:
>
> db.c:5260: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0
> db.c:5336: Test failed: Expected 4, got 8
> db.c:5337: Test failed: Unexpected data
> db.c:5352: Test failed: Unexpected data
> db.c:5378: Test failed: Expected 64, got 68
> db.c:5379: Test failed: Unexpected data
> db.c:6993: Test failed: Expected "", got "grape"
> db.c:6994: Test failed: Expected 0, got 5
> db.c:7052: Test failed: Expected "", got "grape"
> db.c:7053: Test failed: Expected 0, got 5
>

[Dan Kegel-2]

On Sat, Oct 31, 2009 at 8:02 AM, Nathan Gallaher
<ngallaher@...> wrote:
> Could someone give me a pointer as to how you reproduce this trace?  I've
> spent some time fiddling with valgrind, the WINETEST_WRAPPER env var, and
> --enable-maintainer-mode, all to no avail.

I use
http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-daily.sh
but you can more simply do

wine notepad &
cd dlls/msi/tests
valgrind --trace-children=yes --track-origins=yes wine msi_test.exe.so db.c

Today that finds one valgrind error:

==21129== Conditional jump or move depends on uninitialised value(s)
==21129==    at 0xCD6B96A: RtlFreeHeap (heap.c:1460)
==21129==    by 0xD700437: msi_free (msipriv.h:1099)
==21129==    by 0xD70051F: VIEW_find_column (msiquery.c:82)
==21129==    by 0xD714479: SELECT_AddColumn (select.c:392)
==21129==    by 0xD71466F: SELECT_CreateView (select.c:436)
==21129==    by 0xD6F07CD: INSERT_CreateView (insert.c:393)
==21129==    by 0xD72D4B6: sql_parse (sql.y:149)
==21129==    by 0xD72ED6A: MSI_ParseSQL (sql.y:960)
==21129==    by 0xD70083C: MSI_DatabaseOpenViewW (msiquery.c:137)
==21129==    by 0xD700C90: MsiDatabaseOpenViewW (msiquery.c:279)
==21129==    by 0xD70060F: MsiDatabaseOpenViewA (msiquery.c:110)
==21129==    by 0xD541575: test_streamtable (db.c:1443)
==21129==  Uninitialised value was created by a stack allocation
==21129==    at 0xD700443: VIEW_find_column (msiquery.c:60)

If you also want to see memory leaks, add --leak-check=full
- Dan