On Tue, Mar 4, 2014 at 6:01 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 03/03/2014 04:03 PM, Niki Gorchilov wrote:
>
>> FATAL: Squid has attempted to read data from memory that is not
>> present. This is an indication of of (pre-3.0) code that hasn't been
>> updated to deal with sparse objects in memory. Squid should
>> coredump.allowing to review the cause.
>
> I have seen one manifestation of such a bug in Rock and fixed it. IIRC,
> trunk r13295 you are using has that fix, but I am not 100% certain and
> will need to research that. Getting a back trace may be useful.
>
>
>> Unfortunately, no core dumps are available for unknown reason.
>
> That part I am sure about since I faced the same problem: The fatal()
> call that src/stmem.cc code printing the above FATAL message is using
> does not trigger a core dump; it just exits. We should be calling
> fatal_dump() there instead.
>
OK. I've patched src/stmem.cc to use fatal_dump() and will try to
collect a core during the night.
Do you need debug ALL,9? With 150 mbps of traffic, it will be a huge
log for just few seconds of operation I guess.
Best,
Niki
On Tue, Mar 4, 2014 at 6:01 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 03/03/2014 04:03 PM, Niki Gorchilov wrote:
>
>> FATAL: Squid has attempted to read data from memory that is not
>> present. This is an indication of of (pre-3.0) code that hasn't been
>> updated to deal with sparse objects in memory. Squid should
>> coredump.allowing to review the cause.
>
> I have seen one manifestation of such a bug in Rock and fixed it. IIRC,
> trunk r13295 you are using has that fix, but I am not 100% certain and
> will need to research that. Getting a back trace may be useful.
>
>
>> Unfortunately, no core dumps are available for unknown reason.
>
> That part I am sure about since I faced the same problem: The fatal()
> call that src/stmem.cc code printing the above FATAL message is using
> does not trigger a core dump; it just exits. We should be calling
> fatal_dump() there instead.
>
>
> Cheers,
>
> Alex.
>
Received on Tue Mar 04 2014 - 16:45:34 MST
This archive was generated by hypermail 2.2.0 : Tue Mar 04 2014 - 12:00:25 MST