Re: crash on 2G access.log

Adrian Chadd wrote:
>
> On Wed, Oct 30, 2002, Andres Kroonmaa wrote:
> >
> > Had today looping crash after access.log got 2G in size
> > and squid was unable to write to it. Squid segfaulted.
> > is it known issue?
>
> Thats strange. It shouldn't be.
> Unless, we need to use the *64() calls in solaris too..

Just as Linux solaris has two file I/O syscall interfaces. One 32 bit,
one 64 bit. If you compile 32 bit applications to use 64 bit file size
I/O you need to tell this somehow..

Digging around to find details... ah, similar to Linux. Probably a
standard of some sorts:

/*
 * Large file compilation environment control:
 *
 * The setting of _FILE_OFFSET_BITS controls the size of various
file-related
 * types and governs the mapping between file-related source function
symbol
 * names and the corresponding binary entry points.
 *
 * In the 32-bit environment, the default value is 32; if not set, set
it to
 * the default here, to simplify tests in other headers.
 *
 * In the 64-bit compilation environment, the only value allowed is 64.
 */

So the --enable-large-files option of HEAD should work just fine..

Relevant snippet from configure.in:

dnl Enable Large file support
AC_ARG_ENABLE(large-files,
[ --enable-large-files Enable support for large files (>2GB). Still
                          experimental.],
[ if test "$enableval" = "yes" ; then
        echo "Large file support enabled"
        CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=64"
  fi
])

There also appears to be a O_LARGEFILE flag to open(), but this does not
seem to make any difference either way.

It should however be noted that enabling 64 bits file sizes in Squid
still experimentail. Enabling this will enable all files to become 64
bits, and some parts of Squid may still assume file sizes fits in a int
(or in best case long).

Regards
Henrik
Received on Thu Oct 31 2002 - 02:05:26 MST