[squid-users] FATAL: xcalloc: Unable to allocate 18446744073487757627 blocks of 1 bytes!

Amos Jeffries squid3 at treenet.co.nz
Tue Mar 10 08:30:41 UTC 2015


On 10/03/2015 8:44 a.m., HackXBack wrote:
> root at debian:/etc/squid# gdb /usr/sbin/squid /var/spool/squid/cache/squid/core
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 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-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/squid...done.
> [New LWP 7263]
> 
> warning: Can't read pathname for load map: Input/output error.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `(squid-1) -YC -f /etc/squid/squid.conf'.
> Program terminated with signal 6, Aborted.
> #0  0x00007f938c52d165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) backtrace
> #0  0x00007f938c52d165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007f938c5303e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x0000000000573bc5 in fatal_dump (message=0xbaf580 "xcalloc: Unable to
> allocate 18446744073645296089 blocks of 1 bytes!\n") at fatal.cc:138
> #3  0x00000000007ab976 in xcalloc (n=18446744073645296089, sz=1) at
> xalloc.cc:82

Oh darn. These bits ...

> #4  0x00000000bfebfbff in ?? ()
> #5  0x0000000000000006 in ?? ()
> #6  0x0000000000001000 in ?? ()
> #7  0x0000000000000011 in ?? ()
> #8  0x0000000000000064 in ?? ()
> #9  0x0000000000000003 in ?? ()
> #10 0x0000000000400040 in ?? ()
> #11 0x0000000000000004 in ?? ()
> #12 0x0000000000000038 in ?? ()
> #13 0x0000000000000005 in ?? ()
> #14 0x0000000000000008 in ?? ()
> #15 0x0000000000000007 in ?? ()
> #16 0x00007f3c7d951000 in ?? ()
> #17 0x0000000000000008 in ?? ()
> #18 0x0000000000000000 in ?? ()
> (gdb)

Are the ones we need to see symbol names from.

If you self-built it from sources it will need to be rebuilt without
symbol stripping, then a new trace gathered.

If you built it using updated sources under the .deb package there
should be a squid-dbg binary with all the symbol names in to be loaded
by gdb instead of the sbin/squid parameter.


Amos


More information about the squid-users mailing list