Re: Squid 3.2.1 is dumping core

From: Linda W <squid-user_at_tlinx.org>
Date: Fri, 17 Aug 2012 13:55:13 -0700

Alex?:

        Did I catch some unfinished code?

Looks like I am failing after the TODO's with asserts to check
that structures are coming back empty'ed...and they aren't.

*hmmm*....
(store.cc failed code section below..)

void
StoreEntry::startWriting()
{
     Packer p;

     /* TODO: when we store headers serparately remove the header portion */
     /* TODO: mark the length of the headers ? */
     /* We ONLY want the headers */
     packerToStoreInit(&p, this);

     assert (isEmpty()); ###<<<<<------assertion
failed...#1854; TODO?
     assert(mem_obj);

     const HttpReply *rep = getReply();
     assert(rep);

     rep->packHeadersInto(&p);
     mem_obj->markEndOfReplyHeaders();

     rep->body.packInto(&p);

     packerClean(&p);
}

>>
>> Linda W wrote:
>>> Amos Jeffries wrote:
>>>> The Squid HTTP Proxy team is very pleased to announce the availability
>>>> of the Squid-3.2.1 release!
>>> ---
>>> BTW ---
>>> I finally managed to get a good (I think) stack traceback.
>>>
>>>
>>> (N.B. - earlier versions were dumping core, but never got the
>>> debug symbols in correctly for a good stack trackback). This time
>>> I did...
>>>
>>> This look familiar for someone who's doing something wrong or should
>>> squid be more tolerant? ;-)
>>>
>>> Core was generated by `(squid-6)'.
>>> Program terminated with signal 6, Aborted.
>>> #0 0x0000003000434d95 in __GI_raise (sig=6)
>>> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>> 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
>>> (gdb) where
>>> #0 0x0000003000434d95 in __GI_raise (sig=6)
>>> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>> #1 0x00000030004362ab in __GI_abort () at abort.c:93
>>> #2 0x00000000005042e5 in xassert (msg=0x698648 "isEmpty()",
>>> file=<optimized out>, line=1854) at debug.cc:567
>>> #3 0x00000000005938b4 in StoreEntry::startWriting (this=0x27942d0)
>>> at store.cc:1854
>>> #4 0x00000000005a380c in ServerStateData::setFinalReply
>>> (this=0x27ae6c8, rep=
>>> 0x27b9890) at Server.cc:173
>>> #5 0x000000000054b0b0 in HttpStateData::processReply (this=0x27ae6c8)
>>> at http.cc:1168
>>> #6 0x000000000054b28a in HttpStateData::readReply (this=0x27ae6c8,
>>> io=<optimized out>) at http.cc:1145
>>> #7 0x000000000054d0eb in JobDialer<HttpStateData>::dial
>>> (this=0x2814240, call=
>>> ...) at base/AsyncJobCalls.h:175
>>> #8 0x00000000005f9b74 in AsyncCall::make (this=0x2814210) at
>>> AsyncCall.cc:36
>>> #9 0x00000000005fcbb7 in AsyncCallQueue::fireNext (this=<optimized
>>> out>)
>>> at AsyncCallQueue.cc:54
>>> #10 0x00000000005fcd10 in AsyncCallQueue::fire (this=0x2340480)
>>> at AsyncCallQueue.cc:40
>>> #11 0x000000000051168c in EventLoop::runOnce (this=0x7fff6fb3d720)
>>> at EventLoop.cc:131
>>> #12 0x0000000000511758 in EventLoop::run (this=0x7fff6fb3d720)
>>> at EventLoop.cc:95
>>> #13 0x000000000056a29f in SquidMain (argc=<optimized out>,
>>> argv=<optimized out>) at main.cc:1500
>>> #14 0x00000000004beea6 in SquidMainSafe (argv=<optimized out>,
>>> argc=<optimized out>) at main.cc:1215
>>> #15 main (argc=<optimized out>, argv=<optimized out>) at main.cc:1207
>>>
>
Received on Fri Aug 17 2012 - 21:34:13 MDT

This archive was generated by hypermail 2.2.0 : Sat Aug 18 2012 - 12:00:07 MDT