Finally found the cause of my stack smashing and it turned out to be a
MemFree() of a local array.. only reason why the normal tools did not
catch this was that I had forgot to disable mempools.. argh!
As a result of this excersise I have implemented cookie based protection
to mempools and cleaned
On Fri, 23 Jan 2004, David Nicklay wrote:
> This is more of something to add to the 'wishlist' of features for
> squid. Over the almost decade of using squid I keep running into the
> problem of being able to figure out why squid does not want to cache any
> particular object. It would be nic
On Fri, 23 Jan 2004, David Nicklay wrote:
> In refreshIsCachable in refresh.cc, you have this line:
> int reason = refreshCheck(entry, NULL, ESI ? 0 : 60);
>
> I read the comment and cannot fathom why the object cannot be refreshed.
>Even if it can't, it seems like we should be able to
On Fri, 23 Jan 2004, David Nicklay wrote:
> I did some more debugging, and it appears that the Vary header is what
> triggers this problem. When I disable the Vary header from the origin
> servers it works just fine. x-accelerator-vary is enabled in our
> build:./include/autoconf.h:838:#defin
Hi,
In refreshIsCachable in refresh.cc, you have this line:
int reason = refreshCheck(entry, NULL, ESI ? 0 : 60);
I read the comment and cannot fathom why the object cannot be refreshed.
Even if it can't, it seems like we should be able to override this
without modifying the source code an
Hi,
I did some searching and found that the bug we are encountering has
existed since at least squid 2.5
Bug #616
Negative cached 404 replies with VARY header never matches
--
David Nicklay
Location: CNN Center - SE0811A
Office: 404-827-2698Cell: 404-545-6218
Hi,
This is more of something to add to the 'wishlist' of features for
squid. Over the almost decade of using squid I keep running into the
problem of being able to figure out why squid does not want to cache any
particular object. It would be nice to have something which stated very
clearly
Hi,
I did some more debugging, and it appears that the Vary header is what
triggers this problem. When I disable the Vary header from the origin
servers it works just fine. x-accelerator-vary is enabled in our
build:./include/autoconf.h:838:#define X_ACCELERATOR_VARY 1
I am trying to track t
On Fri, 23 Jan 2004, Andres Kroonmaa wrote:
> This would leave more precise and verbose trace of last N^2 debug statements
> that have been passed. After you identify the function that crashes, you
> can take approach I suggested initially to catch the crash with gdb and
> have full backtrace just
On 23 Jan 2004, at 15:07, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Jan 2004, Andres Kroonmaa wrote:
>
> > This works with 3.0 only. But for fun, I tried to extract latest probe
> > trace from a core I had. After some scripting, you'd get something like
> > this, which is intact
Henrik Nordstrom <[EMAIL PROTECTED]> writes:
> On Fri, 23 Jan 2004, Kinkie wrote:
>
>> I think that White Box Linux 3.0 includes a recent GCC snapshot with GCC
>> support. I'm not sure tho, as my install's HDD burned two days ago.
>
> Not as the default compiler I hope.
No. It installs three diff
On Fri, 23 Jan 2004, Andres Kroonmaa wrote:
> This works with 3.0 only. But for fun, I tried to extract latest probe
> trace from a core I had. After some scripting, you'd get something like
> this, which is intact even when stack is completely smashed.
Cool.
It would be quite interesting to
On Fri, 23 Jan 2004, Kinkie wrote:
> I think that White Box Linux 3.0 includes a recent GCC snapshot with GCC
> support. I'm not sure tho, as my install's HDD burned two days ago.
Not as the default compiler I hope.
For mudflap it needs to be a gcc-ssa snapshot release, a work in progress
develo
3.0-PRE3-20040120 does not seem to negative cache anything. I have
refresh_pattern . 1 100% 5 ignore-reload override-lastmod override-expire
and
negative_ttl 60 seconds
But I always get TCP_MISS/404
This used to work. Has the config changed? Where in the code do I need
to start to debug th
On Fri, 23 Jan 2004, Henrik Nordstrom wrote:
> SourceForge is having problems with the CVS service and currently
> contains very old information due to a glitch in switchover to new
> hardware. They are currently working on restoring the current CVS
> repositories from the old server.
>
> Do N
Henrik Nordstrom <[EMAIL PROTECTED]> writes:
> On Thu, 22 Jan 2004, Henrik Nordstrom wrote:
>
>> I will defenitely try the ssp and mudflap approaches immediately (pending
>> installation first..).
>
> mudflap tried, but unfortunately it does not seem to trap this specific
> error. A guess is that
On 22 Jan 2004, at 14:14, Andres Kroonmaa <[EMAIL PROTECTED]> wrote:
> Also, regarding indirect hints, it crossed my mind that you could try
> check out state of *xprof_Timers array. Profiling probes are reset every
> second by event, thus probes that have stop timestamp zero mean active
> pro
On Fri, 2004-01-23 at 18:52, Henrik Nordstrom wrote:
> SourceForge is having problems with the CVS service and currently
> contains very old information due to a glitch in switchover to new
> hardware. They are currently working on restoring the current CVS
> repositories from the old server.
>
SourceForge is having problems with the CVS service and currently
contains very old information due to a glitch in switchover to new
hardware. They are currently working on restoring the current CVS
repositories from the old server.
Do NOT attempt to commit or update any SourceForge based CVS t
19 matches
Mail list logo
