On Tue, 2003-04-22 at 19:36, Ralf Hildebrandt wrote:
> * Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
>
> > Argh, I'm on one of those OS'es. And now?
>
> Forget that. Got a core:
> #0 0xff0b9bf0 in __sigprocmask () from /usr/lib/libthread.so.1
>
> (gdb) bt
> #0 0xff0b9bf0 in __sigprocmask () from /usr/lib/libthread.so.1
> #1 0xff0ae628 in _resetsig () from /usr/lib/libthread.so.1
> #2 0xff0add18 in _sigon () from /usr/lib/libthread.so.1
> #3 0xff0b0e8c in _thrp_kill () from /usr/lib/libthread.so.1
> #4 0xff149b10 in raise () from /usr/lib/libc.so.1
> #5 0xff13512c in abort () from /usr/lib/libc.so.1
> #6 0x000af400 in fatal (message=0xff2b080c "") at tools.c:360
>
> Argh. libc/threads problem?
Weeeird. And this is during swap.state reading during startup?
Are you using aufs for the store dir? (What cache_dir lines do you have
in squid.conf).
Are there more frames in the stack? If not, then it's going to be hard
to id the cause :}.
The good news is that it's a fatal(), not a segfault, so you can
conceptually just up the store logic debug levels (I'll come up with a
suggested level if needed) and it'll hopefully give us some clue from
what gets logged.
Rob
-- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:15:09 MST