Looks like a new bug in argus

[Carter Bullard]

Hey Timo,
Remove the .threads file in the root directory of argus and then start over.
(rm .threads; make clobber; ./configure; make).  I'll remove it from the
distribution later today, when I get back to the office.

Carter

Timo Sühl wrote:
> Hi Peter,
>
> i think the memory leak also affects me. It eats more and more memory 
> and then begins to swap:
>
> cis:~# ps aux | grep argus
> root      4899  0.6 94.8 1434984 983168 ?      Dsl  Aug18   4:26 
> /usr/local/sbin/argus -de cis -w /var/log/argus/argus.out
>
> As i'm not familar with programming ... can you tell me how to disable 
> the threads? Is it "-DARGUS_THREADS=X" in its Makefile?
>
> Timo
>
> Peter Van Epp schrieb:
>>     Another data point: setting the debug level down (til where it 
>> becomes
>> active) in common/argus_util.c breaks the argus:
>>
>> *** common/argus_util.c.orig    2007-08-18 16:37:06.000000000 -0700
>> --- common/argus_util.c.new     2007-08-18 18:16:08.000000000 -0700
>> ***************
>>
>> (this one works OK)
>> *** 1221,1227 ****
>>   #endif
>>      }
>>   #ifdef ARGUSDEBUG
>> !    ArgusDebug (6, "ArgusMalloc (%d) returning 0x%x\n", bytes, retn);
>>   #endif
>>      return (retn);
>>   }
>> --- 1221,1227 ----
>>   #endif
>>      }
>>   #ifdef ARGUSDEBUG
>> !    ArgusDebug (1, "ArgusMalloc (%d) returning 0x%x\n", bytes, retn);
>>   #endif
>>      return (retn);
>>   }
>>
>> (but doing this one with threads enabled hangs)
>>
>> ***************
>> *** 1285,1291 ****
>>      }
>>
>>   #ifdef ARGUSDEBUG
>> !    ArgusDebug (6, "ArgusCalloc (%d, %d) returning 0x%x\n", nitems, 
>> bytes, retn);
>>   #endif
>>      return (retn);
>>   }
>> --- 1285,1291 ----
>>      }
>>
>>   #ifdef ARGUSDEBUG
>> !    ArgusDebug (1, "ArgusCalloc (%d, %d) returning 0x%x\n", nitems, 
>> bytes, retn);
>>   #endif
>>      return (retn);
>>   }
>>
>>
>>     It only gets this far then stops. Disabling threads makes it go 
>> again,
>> so for now I have disabled threads. I'm hoping that looking at the 
>> debug output
>> will tell us what memory is being lost as we should see the allocs 
>> but no frees.
>>
>> Peter Van Epp / Operations and Technical Support Simon Fraser 
>> University, Burnaby, B.C. Canada
>