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