Re: [squid-users] Re: assertion failed

On 04/22/2013 03:21 AM, Alexandre Chappaz wrote:

> can anyone explain to me the meaning/reason of this assertion :
> src/fs/ufs/ufscommon.cc l 706 :
> ......
> assert(sde);
> ......

This assertion indicates a bug in Squid caching code, possibly in the
UFS-based storage code specifically.

The UFS code found a "delete entry E" record in swap.state log and is
now trying to delete E that was previously loaded into the cache.
Current E state indicates that it is cached on disk. However, the
cache_dir where the entry claims to be stored is missing.

I do not know whether the entry itself is corrupted or the code loaded
an entry from a now-missing cache_dir. The bug may be related to changes
in your squid.conf, especially if you removed some cache_dirs.

You should file a bug report (if you have not already) and post the
result of these gdb commands:

  frame 3
  print added
  print *added
  print Config.cacheSwap.swapDirs

  frame 4
  print this
  print *this

More information may be needed to fully triage this.

HTH,

Alex.

> got the backtrace out :
>
> (gdb) bt
> #0 0x00002ba9da45d265 in raise () from /lib64/libc.so.6
> #1 0x00002ba9da45ed10 in abort () from /lib64/libc.so.6
> #2 0x000000000050ae66 in xassert (msg=0x72992f "sde", file=0x729918
> "ufs/ufscommon.cc", line=706) at debug.cc:567
> #3 0x0000000000669c18 in RebuildState::undoAdd (this=<value optimized
> out>) at ufs/ufscommon.cc:706
> #4 0x000000000066b7f4 in RebuildState::rebuildFromSwapLog
> (this=0x16090668) at ufs/ufscommon.cc:570
> #5 0x000000000066bed7 in RebuildState::rebuildStep (this=0x16090668)
> at ufs/ufscommon.cc:411
> #6 0x000000000066c099 in RebuildState::RebuildStep (data=0x366c) at
> ufs/ufscommon.cc:384
> #7 0x000000000064ac68 in AsyncCallQueue::fireNext (this=<value
> optimized out>) at AsyncCallQueue.cc:54
> #8 0x000000000064adc9 in AsyncCallQueue::fire (this=0x366c) at
> AsyncCallQueue.cc:40
> #9 0x0000000000526fa1 in EventLoop::dispatchCalls (this=<value
> optimized out>) at EventLoop.cc:154
> #10 0x00000000005271a1 in EventLoop::runOnce (this=0x7ffff4ac93f0) at
> EventLoop.cc:119
> #11 0x0000000000527338 in EventLoop::run (this=0x7ffff4ac93f0) at
> EventLoop.cc:95
> #12 0x00000000005911b3 in SquidMain (argc=<value optimized out>,
> argv=<value optimized out>) at main.cc:1501
> #13 0x0000000000591443 in SquidMainSafe (argc=13932, argv=0x366c) at
> main.cc:1216
> #14 0x00002ba9da44a994 in __libc_start_main () from /lib64/libc.so.6
>
>
>
>
> Thank you
> Alex
>
> 2013/4/18 Alexandre Chappaz <alexandrechappaz_at_gmail.com>:
>> sorry, I meant "One kid fails to start giving the following assertion"
>>
>> 2013/4/18 Alexandre Chappaz <alexandrechappaz_at_gmail.com>:
>>> Hi,
>>>
>>> In our SMP enabled environnement, I have one kid to start giving the
>>> fooloowing assertion :
>>> 2013/04/18 04:03:43 kid1| assertion failed: ufs/ufscommon.cc:706: "sde"
>>>
>>> I guess it is something related with the store / store rebuiding.
>>> Maybe a malformed object in the cache store?
>>> here the part of the log :
>>>
>>> 2013/04/18 04:03:42 kid1| Store rebuilding is 5.57% complete
>>> 2013/04/18 04:03:42 kid1| Done reading /var/cache/squid/W1 swaplog
>>> (18735 entries)
>>> 2013/04/18 04:03:43 kid1| Accepting SNMP messages on 0.0.0.0:3401
>>> 2013/04/18 04:03:43 kid1| Accepting HTTP Socket connections at
>>> local=0.0.0.0:3128 remote=[::] FD 12 flags=1
>>> 2013/04/18 04:03:43 kid1| assertion failed: ufs/ufscommon.cc:706: "sde"
>>>
>>>
>>> core file is generated, but it seems to be not valid : gdb says :
>>>
>>> gdb /usr/local/squid/sbin/squid 004/core.758
>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2)
>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/local/squid/sbin/squid...done.
>>> Attaching to program: /usr/local/squid/sbin/squid, process 4
>>> ptrace: Opération non permise.
>>> BFD: Warning: /root/004/core.758 is truncated: expected core file size
>>>> = 58822656, found: 20480.
>>> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging
>>> symbols found)...done.
>>> Loaded symbols for /lib64/ld-linux-x86-64.so.2
>>> Failed to read a valid object file image from memory.
>>> Core was generated by `(squid-1) -S -f /etc/squid/squid.conf'.
>>> Program terminated with signal 6, Aborted.
>>> #0 0x00002b6babe7a265 in ?? ()
>>> (gdb) bt
>>> Cannot access memory at address 0x7fff38b1cf98
>>> (gdb) quit
>>>
>>>
>>>
>>>
>>>
>>>
>>> Any clue on how to get a usable core file and/or on the meaning of the
>>> assertion ?
>>>
>>>
>>> Thanks
>>> Alex
Received on Mon Apr 22 2013 - 16:49:46 MDT