Re: Segfault in cfengine 2.0.4b1

[Mark . Burgess]

Brian, since this happens in db_open, a Berkeley function,
my guess is that this is the dreaded red-hat vs db curse
and that somehow the configuration has mixed up the wrong
library version with the wrong header file.
I doubt if this is a bug in cfengine. It works fine for me.


Mark


On 28 Aug, Brian Youngstrom wrote:
> Mark,
> 
> I've recently started to experience a segfault with 2.0.3.  It started
> after I added a 70mb directory to the copy list.  I compiled 2.0.04b1
> and moved cfagent and cfservd into place to see if I was experiencing the
> bug you fixed in 2.0.4b1, same problem.
> 
> cfengine walks the 70mb directory, copies a few files that it believes
> have changed (although they haven't), runs links, then dies with SIGSEGV
> when starting the disable pass.  Here is the crash and backtrace:
> 
> *********************************************************************
>  Main Tree Sched: disable pass 1 @ Wed Aug 28 11:26:36 2002
>  *********************************************************************
> 
> 
>  Program received signal SIGSEGV, Segmentation fault.
>  [Switching to Thread 1024 (LWP 3466)]
>  0x401afa24 in chunk_alloc (ar_ptr=0x40264300, nb=32) at malloc.c:2878
>  2878    malloc.c: No such file or directory.
>          in malloc.c
>          (gdb) backtrace
>          #0  0x401afa24 in chunk_alloc (ar_ptr=0x40264300, nb=32) at
>          malloc.c:2878
>          #1  0x401af828 in __libc_malloc (bytes=28) at malloc.c:2811
>          #2  0x080aa3e7 in __os_malloc ()
>          #3  0x080aa33d in __os_calloc ()
>          #4  0x080a9753 in __memp_open ()
>          #5  0x08093b6f in __dbenv_open ()
>          #6  0x080c38ea in __db_dbenv_setup ()
>          #7  0x080c2f30 in __db_dbopen ()
>          #8  0x080c2d50 in __db_open ()
>          #9  0x0807d776 in InitializeLocks () at locks.c:132
>          #10 0x0807e05a in PutLock (
>              name=0x81840e0
>              "lock.cfagent_conf.andy.disable._etc_hosts_equiv")
>              at locks.c:452
>          #11 0x0807e7f6 in SetLock () at locks.c:424
>          #12 0x0807dbac in GetLock (operator=0x8131c40 "disable", 
>              operand=0x812fc40 "_etc_hosts_equiv", ifelapsed=1, 
> expireafter=120, 
>              host=0x81858e0 "andy", now=1030559150) at locks.c:270
>          #13 0x0805210d in DisableFiles () at do.c:1529
>          #14 0x0804d5d5 in DoTree (passes=2, info=0x81009c9 "Main Tree")
>              at cfagent.c:1142
>          #15 0x0804b648 in main (argc=3, argv=0xbffffad4) at cfagent.c:167
>          #16 0x4014b657 in __libc_start_main (main=0x804b3d0 <main>, argc=3, 
>              ubp_av=0xbffffad4, init=0x804a63c <_init>, fini=0x8100940 
> <_fini>, 
>              rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffacc)
>              at ../sysdeps/generic/libc-start.c:129
> 
> 
> This happens on every run with 2.0.4b1.  It would generally only happen
> when I had two or more cfagents on independant hosts trying to sync the
> same directory simultaneously with 2.0.3.
> 
> Redhat 7.1, local updates and modifications.  All systems running 2.4
> kernels, UP systems.  What other information can I get to you to help
> track this down?



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~