[collectd] Segfaults with collectd 4.0.5 on RHEL 4 U5 x86_64
Ulf Zimmermann
ulf at atc-onlane.com
Wed Aug 15 19:06:14 CEST 2007
> -----Original Message-----
> From: Florian Forster [mailto:octo at verplant.org]
> Sent: Monday, August 06, 2007 14:30
> To: Ulf Zimmermann
> Cc: collectd at verplant.org
> Subject: Re: [collectd] Segfaults with collectd 4.0.5 on RHEL 4 U5
x86_64
>
> Hi Ulf,
>
> On Mon, Aug 06, 2007 at 11:28:37AM -0700, Ulf Zimmermann wrote:
> > I had two systems where collected died this weekend.
>
> do I understand that right that it did work for some time? Those bugs
> are of the especially nasty kind :/
>
> Since this typo of problem is very hard to reproduce, the best change
> you've got is to (re)build collectd with debugging symbols enabled
> (./configure --enable-debug $OTHER_OPTS), enable the creation of a
> corefile (ulimit -c unlimited, or similar, depending on your shell)
and
> ``hope'' that the issue hits once more.
>
> > Aug 4 04:11:09 dbprd01 kernel: collectd[8452]: segfault at
> > 0000000000000000 rip 0000002a993346d0 rsp 0000000042802300 error 4
>
> This isn't of much use, I'm afraid.. What we need to know is the
> position in the code, not the position in memory. The debugging
symbols
> will provide the neccesary glue here. If you have a binary with
> debugging symbols and you have a corresponding corefile, the bug
should
> get it's warm underwear ;)
#0 0x0000002a95f8d6d0 in ps_read_process (pid=30256, ps=0x43203fb0,
state=Variable "state" is not available.
)
at processes.c:525
525 processes.c: No such file or directory.
in processes.c
That is where died twice on one machine in about 4 hours apart.
Ulf.
More information about the collectd
mailing list