Here was the output from the traceback.
(gdb) backtrace
#0 0x00007f9f063ff215 in raise () from /lib64/libc.so.6
#1 0x00007f9f06400cc0 in abort () from /lib64/libc.so.6
#2 0x00007f9f083fa9cf in death (sig=<value optimized out>) at tools.cc:402
#3 <signal handler called>
#4 0x00007f9f06448f4c in memmove () from /lib64/libc.so.6
#5 0x00007f9f083e9d10 in store_client::readHeader (this=0x7f9f09231208,
buf=<value optimized out>, len=3698) at store_client.cc:591
#6 0x00007f9f08417e28 in UFSStoreState::readCompleted (this=0x7f9f0c0e0ac8,
buf=0x7f9fc90f4be0 "\003\237", len=3698, errflag=<value optimized out>,
result=<value optimized out>) at ufs/store_io_ufs.cc:338
#7 0x00007f9f084248be in DiskThreadsDiskFile::readDone
(this=0x7f9f0c0e34e8, rvfd=47,
buf=0x7f9fc90f4be0 "\003\237", len=3698, errflag=0, request={p_ =
0x7fff104bdbf0})
at DiskIO/DiskThreads/DiskThreadsDiskFile.cc:324
#8 0x00007f9f08424bfd in DiskThreadsDiskFile::ReadDone (fd=47,
my_data=0x7f9fc90ee2b8,
buf=0x7f9fc90f4be0 "\003\237", len=3698, errflag=0)
at DiskIO/DiskThreads/DiskThreadsDiskFile.cc:287
#9 0x00007f9f084224d0 in DiskThreadsIOStrategy::callback (this=0x7f9f087cce20)
at DiskIO/DiskThreads/DiskThreadsIOStrategy.cc:146
#10 0x00007f9f083edc6d in StoreHashIndex::callback
(this=0x7f9f0880fa10) at store_dir.cc:742
#11 0x00007f9f083bc673 in StoreRootEngine::checkEvents (this=<value
optimized out>,
timeout=3697) at main.cc:137
#12 0x00007f9f083818b3 in EventLoop::checkEngine (this=0x7fff104bddc0,
engine=0x7fff104bde60,
primary=true) at EventLoop.cc:48
---Type <return> to continue, or q <return> to quit---
#13 0x00007f9f08381a10 in EventLoop::runOnce (this=0x7fff104bddc0) at
EventLoop.cc:120
#14 0x00007f9f08381bb8 in EventLoop::run (this=0x7fff104bddc0) at
EventLoop.cc:100
#15 0x00007f9f083bc0eb in main (argc=<value optimized out>,
argv=0x7fff104bdf88) at main.cc:1334
On Thu, Dec 24, 2009 at 08:57, Dusten Splan <dsplan@xxxxxxxxxxxxxx> wrote:
> So here were the final instructions for getting a core file.
>
> 1. added ulimit -c unlimited to the init.d script.
> 2. installed debug squid rpm package.
> 3. echo 1 > /proc/sys/kernel/core_uses_pid
> 4. echo /corefiles/core-%e-%p-%t > /proc/sys/kernel/core_pattern
>
> Now I have the file:
>
> -rw------- 1 squid squid 5.5G Dec 24 02:33 core-squid-21428-1261639928
>
> All that's left is to run the through gdb.
>
> I'll have more info. soon on what my crash is looking like.
>
> Thanks
> Dusten
>
> On Wed, Dec 23, 2009 at 11:21, Dusten Splan <dsplan@xxxxxxxxxxxxxx> wrote:
>> I just noticed that my ulimit for core dumps was set to 0. I have
>> changed it to unlimited and I hope to see a core file on the next
>> crash.
>>
>> Just as a note so if others have the same issue.
>>
>> To see the ulimit settings
>> ulimit -a
>>
>> To set the core limit
>> ulimit -c unlimited
>>
>> Dusten
>>
>> On Wed, Dec 23, 2009 at 03:41, Kinkie <gkinkie@xxxxxxxxx> wrote:
>>> On Tue, Dec 22, 2009 at 8:54 PM, Dusten Splan <dsplan@xxxxxxxxxxxxxx> wrote:
>>>> I'm seeing my squid processes die and restart. I think it's related
>>>> to a bad cache file but I am unsure how to track it down. I have
>>>> rebuilt the cache by removing the swap.state file and starting squid
>>>> back up.
>>>>
>>>> Here's what I'm seeing in my logs.
>>>>
>>>> 2009/12/21 22:07:01| WARNING: 1 swapin MD5 mismatches
>>>> 2009/12/21 22:07:01| could not parse headers from on disk structure!
>>>> FATAL: Received Segment Violation...dying.
>>>> 2009/12/21 22:07:01| storeDirWriteCleanLogs: Starting...
>>>> 2009/12/21 22:07:01| WARNING: Closing open FD 58
>>>> 2009/12/21 22:07:01| WARNING: Closing open FD 59
>>>> 2009/12/21 22:07:01| 65536 entries written so far.
>>>> 2009/12/21 22:07:01| 131072 entries written so far.
>>>
>>> Please see if you can find a core dump in your coredump_dir. It might
>>> contain valuable information to understand the cause of the problem.
>>>
>>> Please see http://wiki.squid-cache.org/SquidFaq/BugReporting
>>>
>>>
>>> --
>>> /kinkie
>>>
>>
>
