Hi James, could you have a look at yet more fresh valgrind warnings, triggered by http://source.winehq.org/git/wine.git/?a=commit;h=d9ac95be5bb51de2293326920c... ?
You might want to invest in a copy of Valgrind yourself sometime. I can get you a 10% off discount :-)
http://kegel.com/wine/valgrind/logs-2008-07-02/vg-msi_db-diff.txt
+ Conditional jump or move depends on uninitialised value(s) + at msihandle2msiinfo (handle.c:161) + by MsiViewExecute (msiquery.c:467) + by test_storages_table (db.c:6058) + by func_db (db.c:6154) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at test_storages_table (db.c:6000) ... + Use of uninitialised value of size 4 + at MsiCloseHandle (handle.c:290) + by test_storages_table (db.c:6112) + by func_db (db.c:6154) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at test_storages_table (db.c:6000) ... + 8 bytes in 1 blocks are definitely lost + at notify_alloc (heap.c:191) + by RtlReAllocateHeap (heap.c:1428) + by msi_realloc (msipriv.h:962) + by msi_update_table_columns (table.c:1065) + by msi_table_load_transform (table.c:2531) + by msi_table_apply_transform (table.c:2653) + by MSI_DatabaseApplyTransformW (msiquery.c:727) + by MsiDatabaseApplyTransformW (msiquery.c:756) + by MsiDatabaseApplyTransformA (msiquery.c:773) + by test_try_transform (db.c:2431) + by func_db (db.c:6133) + by run_test (test.h:449) + by main (test.h:498)
On Wed, Jul 2, 2008 at 9:40 AM, Dan Kegel dank@kegel.com wrote:
Hi James, could you have a look at yet more fresh valgrind warnings, triggered by http://source.winehq.org/git/wine.git/?a=commit;h=d9ac95be5bb51de2293326920c... ?
You might want to invest in a copy of Valgrind yourself sometime. I can get you a 10% off discount :-)
All of these new valgrind warnings that are products of my patches are a result of testing unimplemented features which will soon be implemented, so I'm not too worried about these. Besides, using valgrind is still a pita, and your patch makes it easier, but it keeps me from being able to 'commit -a'.
Besides, using valgrind is still a pita, and your patch makes it easier, but it keeps me from being able to 'commit -a'.
Why does it prevent that? I just do one junk commit of the valgrind patch, and ignore it when I send in my changes. --Juan
On Wed, Jul 2, 2008 at 11:30 AM, Juan Lang juan.lang@gmail.com wrote:
Besides, using valgrind is still a pita, and your patch makes it easier, but it keeps me from being able to 'commit -a'.
Why does it prevent that? I just do one junk commit of the valgrind patch, and ignore it when I send in my changes.
Personal preference. I don't like having those types of commits in my tree.
On Wed, 2008-07-02 at 10:57 -0500, James Hawkins wrote:
On Wed, Jul 2, 2008 at 9:40 AM, Dan Kegel dank@kegel.com wrote:
Hi James, could you have a look at yet more fresh valgrind warnings, triggered by http://source.winehq.org/git/wine.git/?a=commit;h=d9ac95be5bb51de2293326920c... ?
You might want to invest in a copy of Valgrind yourself sometime. I can get you a 10% off discount :-)
All of these new valgrind warnings that are products of my patches are a result of testing unimplemented features which will soon be implemented, so I'm not too worried about these. Besides, using valgrind is still a pita, and your patch makes it easier, but it keeps me from being able to 'commit -a'.
I don't like being able to do commit -a either, since valgrind errors are considered serious, should the patch be merged upstream?
On Wed, Jul 2, 2008 at 10:52 AM, Adam Petaccia adam@tpetaccia.com wrote:
I don't like being able to do commit -a either, since valgrind errors are considered serious, should the patch be merged upstream?
Alexandre didn't like the patch for some reason earlier. I will have a look and see if I can get rid of the need for a patch (by e.g. adding a "don't valgrind these executables" option to valgrind; then we can valgrind make without, um, valgrinding make).
-
Adam Petaccia -
Dan Kegel -
James Hawkins -
Juan Lang