Looks like a new bug in argus

Carter Bullard carter at qosient.com
Sun Aug 19 21:45:00 EDT 2007


Hey Peter,
So, this is caused by a routine that is trying to get the muxtex on  
the whole modeler
twice, which won't work of course.  I've fixed this, but I think what  
I'm going to do
is get rid of the threads for now, so we can get back on release track
and I'll put threads back in later.

So definitely test without the .threads tag in both argus or the  
clients.

Carter


On Aug 18, 2007, at 9:44 PM, Peter Van Epp wrote:

> 	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
>



More information about the argus mailing list