This sounds a little strange. The trouble with free segfaults is that they are impossible to track down. It might even be the version of libc that you have. Perhaps you could collect a few of these and see if there is a pattern. Often this kind of thing can occur due to build errors, e.g. mixed up library versions. Have you considered rebuilding cfagent?
Mark On Tue, 2005-06-28 at 18:47 -0700, Gary Meyer wrote: > 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 > [EMAIL PROTECTED] > > 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 > > > > > _______________________________________________ > Help-cfengine mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/help-cfengine _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
