Re: r13295: cache_mem + rock store = "memCopy: could not find start of [x,y) in memory"

On 03/04/2014 09:44 AM, Nikolai Gorchilov wrote:
> 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.

If you can collect an ALL,9 cache.log, please do so and keep it in case
it is needed later. If you cannot collect it (for any reason) or its
collection stops Squid from failing, then let's just get the backtrace.

Thank you,

Alex.

> 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 - 17:51:14 MST