Dan Kegel wrote:
> Oh, he'd undoubtedly prefer ignoring to memsetting.
>
I believe the "official" answer is to teach valgrind which fields are
important for which server request. Granted, it a lot more work, but
it's the only way we will actually catch errors :-)
Shachar
> p.s. the mailing list archives seem to be not archiving new messages :-(
Jer restarted mailman and it seems to be fixed now. Presumably a side
effect of the db going nuts yesterday.
cheers,
Jeremy
On Nov 15, 2007 2:33 AM, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> Since wineserver sequests are sent without an attempt to reduce the size of
> written data (and memset(0) is a part of SERVER_START_REQ macro) I'd assume
> that it's ok to do the same for server APC requests. Otherwise server ca
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Oh, he'd undoubtedly prefer ignoring to memsetting.
> But he would like it even better if we can
> avoid sending unneeded bytes. Are the extra
> bytes at the end (they ought to be)? If so,
> whatever decides how many bytes to send could
> be just a bit s
"Dan Kegel" <[EMAIL PROTECTED]> wrote:
> It seems that valgrind doesn't like Ubuntu 7.10; I had
> to drop back to my Feisty system to generate good
> valgrind stack dumps. And the tests didn't hang once!
>
> Results for the last two days are at
> http://kegel.com/wine/valgrind/20071112/
> http:/
"Dan Kegel" <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2007 10:16 PM, Dmitry Timoshkov
>> While looking at the valgrind reports above I noticed that a lot of
>> warnings are triggered in NTDLL_queue_process_apc by the fact that
>> not the whole apc_call_t union is initialized before passing it to
>>
On Nov 14, 2007 10:16 PM, Dmitry Timoshkov
> While looking at the valgrind reports above I noticed that a lot of
> warnings are triggered in NTDLL_queue_process_apc by the fact that
> not the whole apc_call_t union is initialized before passing it to
> the server. In contrast SERVER_START_REQ alway
It seems that valgrind doesn't like Ubuntu 7.10; I had
to drop back to my Feisty system to generate good
valgrind stack dumps. And the tests didn't hang once!
Results for the last two days are at
http://kegel.com/wine/valgrind/20071112/
http://kegel.com/wine/valgrind/20071113/
The logs are trimm
