Tested.
I have made a (small) file of the structures I've noticed past formatting
errors on. With a manual fix-up to what I think it should look like in
readable C++ under the published squid formatting description.
The output of your script does this:
..
It is the
On Thu, 2008-02-07 at 12:21 +0900, Adrian Chadd wrote:
Well, I haven't removed the temporary malloc/free pair, whatever its
called;
I've just removed Amos' workaround in src/comm.cc so it doesn't leak
on my
system whilst I profile.
Still, this is one of those death of a thousand cuts
Uhm, the kernel won't be free'ing userland memory at all; it doesn't give
a rats how its managed.
You're probably confused with the library - the libc is fumbling with
all the struct addrinfo things.
Also, if the bug bugs you, create a temporary pointer and pass that in. ;)
Adrian
On Fri,
On Thu, 2008-02-07 at 14:08 +0900, Adrian Chadd wrote:
On Thu, Feb 07, 2008, Robert Collins wrote:
Still, this is one of those death of a thousand cuts method of
killing performance..
Right, I haven't seen the commit; care to mail the diff?
Which? I just looked at the places where
Have you tried running valgrind?
Also, wait. What exactly are you using addr_info for? Can you explain it
to me?
There's a netural sock addr size type - its called sockaddr_storage.
addr_info is for return results from hostname-ip queries..
Adrian
On Fri, Feb 08, 2008, Amos Jeffries wrote:
Uhm, the kernel won't be free'ing userland memory at all; it doesn't give
a rats how its managed.
You're probably confused with the library - the libc is fumbling with
all the struct addrinfo things.
Possibly. Once an external call is made I no longer care if its kernel or
library. Bad
On Thu, Feb 07, 2008, Robert Collins wrote:
Still, this is one of those death of a thousand cuts method of
killing performance..
Right, I haven't seen the commit; care to mail the diff?
Which? I just looked at the places where Amos is calling GetAddrInfo()
and FreeAddrInfo(); more then
Have you tried running valgrind?
Also, wait. What exactly are you using addr_info for? Can you explain it
to me?
The basics:
addrinfo* extends the neutral sockaddr* type ( union { sockaddr_in,
sockaddr_in6, sockaddr_storage} ) while adding the size values and
moving the flags and protocol
On Fri, Feb 08, 2008, Amos Jeffries wrote:
Try it. You will be horrified.
Why? Whats being trashed, AI, or AI-somemember?
If AI is being trashed, then just create a temporary pointer copy
of AI, use that in the socket call, and then throw it away.
if its trashing the memory -at- the AI rather
On Fri, Feb 08, 2008, Amos Jeffries wrote:
Try it. You will be horrified.
Why? Whats being trashed, AI, or AI-somemember?
AI-somemember.
If AI is being trashed, then just create a temporary pointer copy
of AI, use that in the socket call, and then throw it away.
if its trashing the
And which version of debian on which platform is showing the busted behaviour?
Adrian
On Fri, Feb 08, 2008, Amos Jeffries wrote:
On Thu, 2008-02-07 at 12:21 +0900, Adrian Chadd wrote:
Well, I haven't removed the temporary malloc/free pair, whatever its
called;
I've just removed
And which version of debian on which platform is showing the busted
behaviour?
Dell i386
Kernels 2.6.18-4 thru 2.6.22-2
libstdc6 with g++ 4.1 thru 4.3
All the debian setups I have had to test with basically since I first
found it.
Amos
On Fri, Feb 08, 2008, Amos Jeffries wrote:
On
Tested.
I have made a (small) file of the structures I've noticed past
formatting
errors on. With a manual fix-up to what I think it should look like in
readable C++ under the published squid formatting description.
The output of your script does this:
..
It is the
On Fri, 2008-02-08 at 11:46 +1300, Amos Jeffries wrote:
The basics:
addrinfo* extends the neutral sockaddr* type ( union { sockaddr_in,
sockaddr_in6, sockaddr_storage} ) while adding the size values and
moving the flags and protocol details.
Hi Amos,
I understand that we need to
On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
Do we need something like that? Any comments/suggestions? Any testers?
I believe we do and I appreciate you working on it! Please try to fix
the remaining problems Amos pointed out.
Also, can you apply it to the entire Squid tree,
On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
Do we need something like that? Any comments/suggestions? Any testers?
I believe we do and I appreciate you working on it! Please try to fix
the remaining problems Amos pointed out.
Also, can you apply it to the entire Squid tree,
On Fri, 2008-02-08 at 14:31 +1300, Amos Jeffries wrote:
On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
Do we need something like that? Any comments/suggestions? Any testers?
I believe we do and I appreciate you working on it! Please try to fix
the remaining problems Amos
On Fri, 2008-02-08 at 11:46 +1300, Amos Jeffries wrote:
The basics:
addrinfo* extends the neutral sockaddr* type ( union { sockaddr_in,
sockaddr_in6, sockaddr_storage} ) while adding the size values and
moving the flags and protocol details.
Hi Amos,
I understand that we need to
On Fri, 2008-02-08 at 14:31 +1300, Amos Jeffries wrote:
On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
Do we need something like that? Any comments/suggestions? Any
testers?
I believe we do and I appreciate you working on it! Please try to fix
the remaining problems Amos
On Fri, Feb 08, 2008, Amos Jeffries wrote:
sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
provide a better way of using sockaddr* so the sockaddr_in and
sockaddr_in6 bits could be read-written easily. But the big/litte endian
problems between OS screwed up the
On Fri, Feb 08, 2008, Amos Jeffries wrote:
sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
provide a better way of using sockaddr* so the sockaddr_in and
sockaddr_in6 bits could be read-written easily. But the big/litte endian
problems between OS screwed up the
On Fri, 2008-02-08 at 15:52 +1300, Amos Jeffries wrote:
The second;
sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
provide a better way of using sockaddr* so the sockaddr_in and
sockaddr_in6 bits could be read-written easily. But the big/litte endian
problems between
22 matches
Mail list logo
