Julian kindly pointed out that --vex-iropt-precise-memory-exns=yes is needed
to avoid false positives in tricky signal handlers like the one
involved in GetBitmapBits().
Adding that didn't slow things down much if any, and got rid of lots
of valgrind-specific GetBitmapBits() crashes.
Also, I appli
This is with an almost-unpatched trunk (the only patch
is my tweak to handle bogus environment variables),
so it's now using Alexandre's heap patches rather
than mine.
There are some interesting new warnings, not sure
quite what to make of them yet.
Logs at
http://kegel.com/wine/valgrind/logs/2010
On Fri, Nov 20, 2009 at 9:02 AM, Nikolay Sivov wrote:
> Dan Kegel wrote:
>> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt
>> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt
>> show a more inscrutable error:
>> Invalid write of size 4
>> at
Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt
show a more inscrutable error:
Invalid write of size 4
at TAB_SetCurSel (tab.c:255)
by TAB_WindowProc (tab.c:3367)
by
On Thu, Nov 19, 2009 at 11:16 PM, Dan Kegel wrote:
> On Thu, Nov 19, 2009 at 8:38 PM, Nikolay Sivov wrote:
>>> I'm not sure about the user (i.e. developer) interface for turning the
>>> heap
>>> check on. Should it be automatic when one does warn+heap?
>>
>> If I got it right it makes sense to e
On Thu, Nov 19, 2009 at 8:38 PM, Nikolay Sivov wrote:
>> I'm not sure about the user (i.e. developer) interface for turning the
>> heap
>> check on. Should it be automatic when one does warn+heap?
>
> If I got it right it makes sense to enable this only running under valgrind
> control?
Nope. I
Dan Kegel wrote:
On Thu, Nov 19, 2009 at 7:37 AM, Nikolay Sivov wrote:
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/
is the first full run with the heap tail check enabled.
So you use some private patches for that, why aren't they merged?
'Cause I just wrote it an hour
On Thu, Nov 19, 2009 at 7:37 AM, Nikolay Sivov wrote:
>> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/
>> is the first full run with the heap tail check enabled.
>
> So you use some private patches for that, why aren't they merged?
'Cause I just wrote it an hour before that message?
I alr
Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/
is the first full run with the heap tail check enabled.
So you use some private patches for that, why aren't they merged?
Here are the first few new problems it found.
Somehow, it found a bunch of invalid reads in
http:/
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/
is the first full run with the heap tail check enabled.
Here are the first few new problems it found.
Somehow, it found a bunch of invalid reads in
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_crypt.txt
all in a function ca
Yesterday's valgrind results are at
http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/
These were done with updated suppressions; see
http://code.google.com/p/winezeug/source/list?path=/trunk/valgrind/valgrind-suppressions
so don't get too excited about errors going away.
(I really should inclu
Dan Kegel schrieb:
> 2009/10/28 André Hentschel :
>> I think i found a false postitv. its
>> http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/vg-ntdll_env.txt
>> the code in ntdll/tests/env.c looks like:
>>...
>>name.Buffer = bn;
>>...
>>value.Buffer = bv;
>>
http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/
has current results. I've tweaked the diff-* files
to be brutally minimalist, so if there's a diff- file,
it's more likely to be interesting. On the downside,
you have to look at the non-diff file to see line numbers.
One of these days I've g
Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with
all of the log files I used to generate.
...
listview seems genuinely improved:
http://kegel.com/wine/valgrind/logs/2009-10-22-19.57/vg-comctl32_listview.txt
is a lot shorter than
http://kegel.com/wine
On Fri, Oct 23, 2009 at 10:27 AM, Alexandre Julliard
wrote:
>> For process termination it's harmless, but for explicit unload it's a
>> leak. Probably a similar thread data tracking
>> should be added here too.
>
> In theory yes, but in general that's not necessary. Particularly for
> something li
Nikolay Sivov writes:
> For process termination it's harmless, but for explicit unload it's a
> leak. Probably a similar thread data tracking
> should be added here too.
In theory yes, but in general that's not necessary. Particularly for
something like msvcrt that won't get loaded and unloaded
Dan Kegel wrote:
MSDN says
"When a DLL is unloaded from a process as a result of an unsuccessful
load of the DLL, termination of the process, or a call to FreeLibrary,
the system does not call the DLL's entry-point function with the
DLL_THREAD_DETACH value for the individual threads of the proces
Dan Kegel wrote:
On Fri, Oct 23, 2009 at 9:37 AM, Nikolay Sivov wrote:
Did I miss something?
Sorry, I'm not fully awake (and I think the last time I was fully awake was
some time before I had children :-).
Same here I can tell you.
MSDN says
"When a DLL is unloaded from a process
On Fri, Oct 23, 2009 at 9:37 AM, Nikolay Sivov wrote:
> Did I miss something?
Sorry, I'm not fully awake (and I think the last time I was fully awake was
some time before I had children :-).
MSDN says
"When a DLL is unloaded from a process as a result of an unsuccessful
load of the DLL, terminat
Dan Kegel wrote:
On Fri, Oct 23, 2009 at 9:19 AM, Nikolay Sivov wrote:
Looking at msvcrt.dll._fcvt leak reported in recent results it's not quite
clear for me how could this happen.
It uses heap block allocated as thread data and it should be freed on
DLL_THREAD_DETACH.
Really? I don
On Fri, Oct 23, 2009 at 9:19 AM, Nikolay Sivov wrote:
> Looking at msvcrt.dll._fcvt leak reported in recent results it's not quite
> clear for me how could this happen.
> It uses heap block allocated as thread data and it should be freed on
> DLL_THREAD_DETACH.
Really? I don't see it being freed
Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with
all of the log files I used to generate. For instance,
http://kegel.com/wine/valgrind/logs/2009-10-22-19.57-summary.txt
is a diff of just the first line of each error, to give you
a quick idea what changed.
http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with
all of the log files I used to generate. For instance,
http://kegel.com/wine/valgrind/logs/2009-10-22-19.57-summary.txt
is a diff of just the first line of each error, to give you
a quick idea what changed. (The logs are pre
On Thu, Oct 22, 2009 at 7:28 AM, Nikolay Sivov wrote:
> Dan, do I need something special to
> build current valgrind? Is there any special gcc/binutils requirements?
I don't think there are any special tool requirements (other than
possibly "don't use binutils-gold", but that's true for wine as w
Dan Kegel wrote:
I added suppressions for a few frequent spurious warnings and reran,
the updated results are in
http://kegel.com/wine/valgrind/logs/2009-10-21-19.42.log
and broken out by test in
http://kegel.com/wine/valgrind/logs/2009-10-21-19.42/
Please send me the suppression record for any
It varies. I got a leakfix in yesterday, for instance.
On Oct 22, 2009 5:51 AM, "Ben Klein" wrote:
2009/10/22 Dan Kegel :
> 2) Fixing leaks in test code is usually pretty safe, and > it's easier to
get Alexandre to accept ...
I thought AJ didn't like leak fixes in the tests.
Ben Klein wrote:
> 2009/10/22 Dan Kegel :
>> 2) Fixing leaks in test code is usually pretty safe, and
>> it's easier to get Alexandre to accept simple patches to tests,
>> so start with those if you don't have many patches under your belt.
>
> I thought AJ didn't like leak fixes in the tests.
He d
2009/10/22 Dan Kegel :
> 2) Fixing leaks in test code is usually pretty safe, and
> it's easier to get Alexandre to accept simple patches to tests,
> so start with those if you don't have many patches under your belt.
I thought AJ didn't like leak fixes in the tests.
I added suppressions for a few frequent spurious warnings and reran,
the updated results are in
http://kegel.com/wine/valgrind/logs/2009-10-21-19.42.log
and broken out by test in
http://kegel.com/wine/valgrind/logs/2009-10-21-19.42/
Please send me the suppression record for any warnings that are
29 matches
Mail list logo
