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@xxxxxxxxx>: >> sorry, I meant "One kid fails to start giving the following assertion" >> >> 2013/4/18 Alexandre Chappaz <alexandrechappaz@xxxxxxxxx>: >>> 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
