[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Segmentation Fault in cfagent on RH EL-3.0 updates 3,5
From: |
Gary Meyer |
Subject: |
Re: Segmentation Fault in cfagent on RH EL-3.0 updates 3,5 |
Date: |
Tue, 28 Jun 2005 18:47:22 -0700 |
Let me clarify a bit, this is : Red Hat Enterprise Linux WS release 3
(Taroon Update 5)
(I've also tried Update 3, and get basically the same thing)
I've a particular instance in the debugger, and it shows me:
(gdb) where
#0 0x0027e08d in _int_free () from /lib/tls/libc.so.6
#1 0x0027d048 in free () from /lib/tls/libc.so.6
#2 0x002b0c28 in closedir () from /lib/tls/libc.so.6
#3 0x0807e945 in RecursiveLink (lp=0x87736e8,
from=0xbffe3d20
"/usr/pkg/lib/perl5/site_perl/5.8.2/i686-linux/DBI/Const/GetInfo",
to=0x341180 "\001", maxrecurse=-107) at link.c:383
#4 0x0807eaf9 in RecursiveLink (lp=0x87af570,
from=0xbffe5dc0
"/usr/pkg/lib/perl5/site_perl/5.8.2/i686-linux/DBI/Const",
to=0xbffe4dc0
"/pcom/distrib/swtools/perlmods/DBI/v1.39/rh9/i86/lib/perl5/site_perl/
5.8.2/i686-linux/DBI/Const", maxrecurse=-106) at link.c:356
...
So maxrecurse tells me we're 8 levels deep in recursion here. Also
note that in frame 3, the pointer for the "to" variable (0x341180)
looks like it's a few digits short ... so I do this:
(gdb) frame 4
#4 0x0807eaf9 in RecursiveLink (lp=0x87af570,
from=0xbffe5dc0
"/usr/pkg/lib/perl5/site_perl/5.8.2/i686-linux/DBI/Const",
to=0xbffe4dc0
"/pcom/distrib/swtools/perlmods/DBI/v1.39/rh9/i86/lib/perl5/site_perl/
5.8.2/i686-linux/DBI/Const", maxrecurse=-106) at link.c:356
356 RecursiveLink(lp,newfrom,newto,maxrecurse-1);
(gdb) print newto
$19 =
"/pcom/distrib/swtools/perlmods/DBI/v1.39/rh9/i86/lib/perl5/site_perl/
5.8.2/i686-linux/DBI/Const/GetInfo\000rlmods/DBI/v1.39/rh9/i86/lib/
perl5/site_perl/5.8.2/i686-linux/DBD/Sponge.pm\000m\00039/rh9/i86/lib/
per"...
(gdb) frame 3
#3 0x0807e945 in RecursiveLink (lp=0x87736e8,
from=0xbffe3d20
"/usr/pkg/lib/perl5/site_perl/5.8.2/i686-linux/DBI/Const/GetInfo",
to=0x341180 "\001", maxrecurse=-107) at link.c:383
383 closedir(dirh);
(gdb) print to
$20 = 0x341180 "\001"
Note that the value of newto in the call to RecursiveLink (in frame 4)
isn't the same as the value of to in frame 3 ... which I think means
the heap is getting stepped on. Note: the value of newto DOES have a
null character in it after "/Const/Getinfo" about 103 characters into
the string.
=============================
Gary Meyer
Configuration Management Engineer
Process Engineering
Caspian Networks
gmeyer@caspiannetworks.com
On Jun 28, 2005, at 5:40 PM, Tim Nelson wrote:
On Tue, 28 Jun 2005, Gary Meyer wrote:
I can't seem to get cfagent (I'm using 2.1.15, the latest) to run
successfully on Red Hat Enterprise Linux 3.0 update 3, or update 5.
It works fine on EL 3.0 with no updates, and I haven't tried the
other updates, but I suspect somewhere between no updates and Update
3, something breaks cfagent. It seems to generate a segmentation
fault at a different place each time, though if I run with -n, then
it'll seg fault at the same place every time. It's always in the
middle of a very large section of recursive link creations. Most of
the time it seems to seg fault on readlink, symlink, or closedir
system calls being called from link.c.
My company uses Red Hat Enterprise Linux 3.0, and most of the
computers are at 3.0 with no updates, but a few of the newly
purchased computers have driver issues, and they work fine with
either update 3 or 5 ... but now my CFEngine scripts blow up. Has
anyone else seen this, or better yet does anyone know how to solve
the problem ?
Interesting. I'm probably not doing the size of link creation that
you are, but it works for me on Redhat ES (update 4).
Any idea what kind of values are being passed to the
readlink/symlink/etc? (I'm wondering about buffer overflows or
something here).
--
Kind Regards,
Tim Nelson
Server Administrator