# frequent segfaults in dansguardian - severe performance impa

## DawgG

i run dansguardian on a mission-critical proxyserver and it throws a lot of segfaults most of which go unnoticed but right now it's so many that users are complaining (and rightfully so).

```

<SNIP>

dansguardian[20189]: segfault at 414 ip 000000000040a593 sp 00007fffec58f480 error 4 in dansguardian[400000+93000]

dansguardian[20307]: segfault at 414 ip 000000000040a593 sp 00007fffec58f480 error 4 in dansguardian[400000+93000]

dansguardian[20162]: segfault at 414 ip 000000000040a593 sp 00007fffec58f480 error 4 in dansguardian[400000+93000]

dansguardian[20308]: segfault at 414 ip 000000000040a593 sp 00007fffec58f480 error 4 in dansguardian[400000+93000]

__ratelimit: 1 callbacks suppressed

<SNIP>
```

even though this problem exists for other ppl as well i have found nothing useful about this on the web or in the forums (except for my own old post https://forums.gentoo.org/viewtopic-p-6050527.html (which was about similar, but different problems)). about a month ago i recompiled glibc and dansguarian which alleviated the problem a little bit (<10segfaults/day, no noticeable performance impact) but now it is much worse.

restarting the service helps a little bit; and i just recompiled glibc, libtool and dansguardian - no more segfaults since 10 minutes. but i'd really like  the problem to get solved. the system's settings are quite conservative and stable, no experimental or "performance enhancing" stuff:

```

squid ~ # emerge --info

Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.11.2-r0, 2.6.31-gentoo-r10 x86_64)

=================================================================

System uname: Linux-2.6.31-gentoo-r10-x86_64-Intel-R-_Xeon-R-_CPU_E5410_@_2.33GHz-with-gentoo-1.12.13

Timestamp of tree: Wed, 18 Aug 2010 14:15:02 +0000

app-shells/bash:     4.0_p37

dev-lang/python:     2.6.5-r2

sys-apps/baselayout: 1.12.13

sys-apps/sandbox:    1.6-r2

sys-devel/autoconf:  2.65

sys-devel/automake:  1.10.3, 1.11.1

sys-devel/binutils:  2.20.1-r1

sys-devel/gcc:       4.3.4, 4.4.3-r2

sys-devel/gcc-config: 1.4.1

sys-devel/libtool:   2.2.6b

virtual/os-headers:  2.6.30-r1

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="* -@EULA"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=native -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-march=native -O2 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="assume-digests buildpkg distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans use

rfetch userpriv usersandbox"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LINGUAS="de en"

MAKEOPTS="-j9"
```

----------

## naelq

did you try emerging/compiling DansGuardian with -O0 optimization level?! (instead of your current -O2)

nael

----------

## DawgG

 *Quote:*   

> did you try emerging/compiling DansGuardian with -O0 optimization level

 

thx for the tip, but no, since i did have some problems with some pkgs (although on different systems) not compiling at all without -O2 and one of the devs (i think flameyes) advised me to always use -O2: https://forums.gentoo.org/viewtopic-t-837853.html

i'll see how the box keeps up and try that maybe.

THX.

----------

## naelq

to be honest, i can not provide an accurate scientific answer/explanation, but with -O0 you'll be forcing GCC to perform minimum (zero?!) optimizations..

& if you would ask about the reason for this suggestion, well, i've happened to have similar problem/issue with some code i work on..

nael

----------

## krinn

as dansguardian filter stuff, i suppose it filter by dns or resolve dns, and it's a know fact glibc is fucked up with dns resolving when using ipv6 (saw many users with troubles and weirdness when resolving ipv6 with many glibc versions, try google it)

So if enable, i would try to disable ipv6 and see if it improve things

and i would also add, as it always segfault at the same place, when the same conditions are met it just segfault, so a bug or at a bare minimum a dirty coded application (i would expect it to handle a strange condition and issue an error instead of accepting it and segfaulting like that)

----------

