Apiset Tananchai writes:
>> >(squid): client_side.c:399: clientHandleIMSReply: Assertion `entry->store_s
tat
>> us != STORE_ABORTED' failed.
>> >(squid): client_side.c:399: clientHandleIMSReply: Assertion `entry->store_s
tat
>> us != STORE_ABORTED' failed.
>> >
>> >What debug info do you need to solve this problem? I currently set
>> >debug ALL,1 in squid.conf and see nothing in cache.log that may relate to
>> >this problem.
>>
>> The best place to start is with a stack trace from a debugger (gdb or
>> dbx).
>>
>> The assertion should cause a core file to be generated. You can
>> use this core file to get a stack trace. Instructions are at
>> http://squid.nlanr.net/Squid/FAQ/FAQ-11.html#ss11.18
>> if you need them.
>
>Hi Duane,
>
>I tried to find the core file but it looks like Linux does not generate it
>since asyncIO was enabled and LinuxThread was used. From section G.2 of
>LinuxThread FAQ (http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html)
>
>-- quote --
>G.2: Does it work with post-mortem debugging?
>
>Not very well. Generally, the core file does not correspond to the thread
>that crashed. The reason is that the kernel will not dump core for a
>process that shares its memory with other processes, such as the other
>threads of your program. So, the thread that crashes silently disappears
>without generating a core file. Then, all other threads of your program
>die on the same signal that killed the crashing thread. (This is required
>behavior according to the POSIX standard.) The last one that dies is no
>longer sharing its memory with anyone else, so the kernel generates a core
>file for that thread. Unfortunately, that's not the thread you are
>interested in.
>-- end quote --
>
>I think you should mention this in the faq. BTW, since I don't have a core
>dump file to generate stack trace, do you have other suggestion?
In this case, squid is not generating a coredump from a thread
process. The code with the assertion always only executes in
the main process, never in a thread.
Duane W.
Received on Thu Sep 24 1998 - 13:16:22 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:11 MST