On Tue, 2008-03-25 at 10:23 +1300, Amos Jeffries wrote:
I found that in 3.x as well. It turns out those bits of valgrind code
only occur if both --enable-leakfinder and --with-valgrind-debug are
enabled.
My test script only had --with-valgrind which wasn't doing even the
job it needed
On Sun, 2008-03-23 at 20:37 +0900, Adrian Chadd wrote:
On Mon, Mar 24, 2008, Amos Jeffries wrote:
Adrian Chadd wrote:
You can ignore that. If you care that much about the epoll error then
just bzero() the data being passed into epoll_ctl() before its called.
I care about every potential
Henrik Nordstrom wrote:
On Tue, 2008-03-25 at 10:23 +1300, Amos Jeffries wrote:
I found that in 3.x as well. It turns out those bits of valgrind code
only occur if both --enable-leakfinder and --with-valgrind-debug are
enabled.
My test script only had --with-valgrind which wasn't doing even
On Tue, 2008-03-25 at 12:23 +1100, Robert Collins wrote:
Is it valgrind being wrong, or does epoll actually read from that
unitinitialised region?
it's valgrind not knowing (or caring about) the full details of when
epoll uses what of the supplied data.
But generally speaking it's a good
On Mon, 2008-03-24 at 00:16 +1300, Amos Jeffries wrote:
I care about every potential cause of trouble in squid. Particularly
avoidable ones that pop up all the time. 'Zero errors' policy and all that.
It may be that this is fixable by setting the first byte of the buffer
to '\0'. I'm just
Henrik Nordstrom wrote:
On Mon, 2008-03-24 at 00:16 +1300, Amos Jeffries wrote:
I care about every potential cause of trouble in squid. Particularly
avoidable ones that pop up all the time. 'Zero errors' policy and all that.
It may be that this is fixable by setting the first byte of the
Just doing a quick check with valgrind I'm seeing a lot of errors in the
event system.
Syscall param epoll_ctl(event) points to uninitialised byte(s)
with a wide range of events like:
==25761==at 0x4559A59: epoll_ctl (in /lib/libc-2.7.so)
==25761==by 0x8171C2F: comm_read(int, char*,
You can ignore that. If you care that much about the epoll error then
just bzero() the data being passed into epoll_ctl() before its called.
adrian
On Mon, Mar 24, 2008, Amos Jeffries wrote:
Just doing a quick check with valgrind I'm seeing a lot of errors in the
event system.
Syscall
Adrian Chadd wrote:
You can ignore that. If you care that much about the epoll error then
just bzero() the data being passed into epoll_ctl() before its called.
I care about every potential cause of trouble in squid. Particularly
avoidable ones that pop up all the time. 'Zero errors' policy
On Mon, Mar 24, 2008, Amos Jeffries wrote:
Adrian Chadd wrote:
You can ignore that. If you care that much about the epoll error then
just bzero() the data being passed into epoll_ctl() before its called.
I care about every potential cause of trouble in squid. Particularly
avoidable ones
Adrian Chadd wrote:
On Mon, Mar 24, 2008, Amos Jeffries wrote:
Adrian Chadd wrote:
You can ignore that. If you care that much about the epoll error then
just bzero() the data being passed into epoll_ctl() before its called.
I care about every potential cause of trouble in squid. Particularly
On Mon, Mar 24, 2008, Amos Jeffries wrote:
Thats cool. There's just bigger fish to fry. :)
Like why '--with-valgrind' doesn't enable the initialisation code
somebody already added to squid for those minor ones
Trying leakfinder + valgrind now.
Heh, valgrind makes it mostly easy to
12 matches
Mail list logo
