Looks like a new bug in clients ...

[Carter Bullard]

Hey Peter,
You're problems could be caused by poor thread scheduling.
I know that some threads packages end up starving some
threads if there is lots of competition.

Do you have anyway of looking at how threads are running
on a processor on your machine?  Do you have more than
one processor?

Carter


On Aug 18, 2007, at 1:28 PM, Carter Bullard wrote:

> This is getting depressing.  and, its time for real remedies.
> I'm away today, but I'll try to make some basic surgical steps
> to get to the bottom of this memory leak, possibly tonight.
>
> Carter
>
> On Aug 18, 2007, at 1:08 PM, Peter Van Epp wrote:
>
>> On Sat, Aug 18, 2007 at 01:36:07AM -0400, Carter Bullard wrote:
>>> Hey Peter,
>>> In your patch, the second call needs to be an unlock:
>>> --- 351,357 ----
>>>
>>>        } else
>>>           done++;
>>>     }
>>> ! #if defined(ARGUS_THREADS)
>>>     pthread_mutex_lock(&queue->lock);
>>>  #endif
>>>
>>> That should be a pthread_mutex_unlock(....)  That works much  
>>> better ;o)
>>> Carter
>>>
>> 	Ah! I didn't even think to look at the code in the locks, just that
>> there shouldn't be a ! in front of the defined(ARGUS_THREADS) :-).
>> 	Clients running threaded looks to have an output file problem (this
>> is on my Mac). Around 19:00 I changed back from unthreaded to  
>> threaded clients
>> and archiving screwed up a bit later:
>>
>> -rw-r--r--   1 vanepp  vanepp   33981508 Aug 17 08:00 com_argus. 
>> 2007.08.17.07.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp   36480665 Aug 17 08:22 com_argus. 
>> 2007.08.17.08.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  197615602 Aug 17 10:00 com_argus. 
>> 2007.08.17.09.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  174326612 Aug 17 10:20 com_argus. 
>> 2007.08.17.10.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  309033292 Aug 17 11:43 com_argus. 
>> 2007.08.17.11.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  161719258 Aug 17 13:00 com_argus. 
>> 2007.08.17.12.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  476553769 Aug 17 14:00 com_argus. 
>> 2007.08.17.13.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp   55332786 Aug 17 15:00 com_argus. 
>> 2007.08.17.14.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  511566867 Aug 17 16:00 com_argus. 
>> 2007.08.17.15.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  394054147 Aug 17 17:00 com_argus. 
>> 2007.08.17.16.00.02.0.gz
>> -rw-r--r--   1 vanepp  vanepp   48935926 Aug 17 18:00 com_argus. 
>> 2007.08.17.17.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp   24995067 Aug 17 19:00 com_argus. 
>> 2007.08.17.18.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp   15496756 Aug 17 19:56 com_argus. 
>> 2007.08.17.19.00.01.0.gz
>> -rw-r--r--   1 vanepp  vanepp  153435576 Aug 17 21:00 com_argus. 
>> 2007.08.17.20.00.00.0.gz
>> -rw-r--r--   1 vanepp  vanepp  105688433 Aug 17 21:23 com_argus. 
>> 2007.08.17.21.00.00.0.gz
>>    (no more output after this point ...)
>> 	As well the argus (unthreaded for now :-)) looks to still be leaking
>> memory:
>>
>> ps auxwwww | grep argus
>> root     22678  1.1 96.6 4977904 3805960 ?     DLs  Aug17   9:24  
>> argus -dJR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
>> vanepp   23816  0.0  0.0   3132   832 pts/1    S+   10:07   0:00  
>> grep argus
>> vanepp at hcids:~>
>>
>> 	I'll see if I have time to recompile both (clients without  
>> threads and
>> argus with) and restart them before I have to go out for a while  
>> and see what
>> happens later.
>>
>> Peter Van Epp / Operations and Technical Support
>> Simon Fraser University, Burnaby, B.C. Canada
>>
>
>