--
[ Picked text/plain from multipart/alternative ]
My first crash with this:
void C_HL2MP_Player::Initialize( void )
{
m_headYawPoseParam = LookupPoseParameter( "head_yaw" );
GetPoseParameterRange( m_headYawPoseParam, m_headYawMin, m_headYawMax );
m_headPitchPoseParam = LookupPoseParameter( "head_pitch" );
GetPoseParameterRange( m_headPitchPoseParam, m_headPitchMin,
m_headPitchMax );
CStudioHdr *hdr = GetModelPtr();
for ( int i = 0; i < hdr->GetNumPoseParameters() ; i++ )
On 9/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>
> New patch available:
>
> http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert
>
> Since the scopes were moved higher, it's a little harder to say that the
> patch is airtight. But it fixes everything trivially encountered by just
> loading up HL2DM and moving around a bit.
>
> At 2006/09/02 06:06 PM, [EMAIL PROTECTED] wrote:
> >Thanks, I'm going to assume this means that FrameLocking is an expensive
> operation and would cause noticeable slow-down machines if done too
> frequently. I haven't noticed any problems, but I'll develop another patch
> with the locks up higher in the stack.
> >
> >It sure would be nice to document this API, since modders can't read the
> closed-source code.
> >
> >So my comment in the wiki is correct though that all of those spots
> represent potential crashers?
> >
> >-bk
> >
> >At 2006/09/02 05:40 PM, Jay Stelly wrote:
> >>No, we just rely on virtual memory for that. This is for when you hit
> >>the cache ceiling (which is usually 256MB depending on the physical ram
> >>on the machine). Obviously on consoles it's lower given the usual
> >>memory configurations there (which isn't relevant to any of you guys,
> >>but is to us).
> >>
> >>Also, I would definitely NOT recommend the code changes you posted on
> >>the wiki. That will cause way too much overhead to protect against a
> >>pointer dangling. The scope frames should be at a much higher level.
> >>
> >>Jay
> >>
> >>
> >>> -----Original Message-----
> >>> From: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED] On Behalf Of
> >>> [EMAIL PROTECTED]
> >>> Sent: Saturday, September 02, 2006 12:17 PM
> >>> To: [email protected]
> >>> Subject: RE: [hlcoders] AssertOnce( pModelCache->IsFrameLocking() );
> >>>
> >>> So if the box is low on ram, the HL2 core will memory it's
> >>> not actively using right that moment? I think I now
> >>> understand what the issue is, although I'm confused by the
> >>> use of scope locking for something like this.
> >>>
> >>> In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's
> >>> instruction, and the result is several dozen fixes, added to
> >>> the KI list:
> >>>
> >>> http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#
> >>> IsFrameLocking_assert
> >>>
> >>> Confirmation from Valve would be appreciated that this is
> >>> correct with respect to the way the closed-source core works.
> >>>
> >>> -bk
> >>>
> >>> At 2006/08/30 09:02 PM, Jay Stelly wrote:
> >>> >Since there are no explicit unlock operations on the studio
> >>> headers we
> >>> >use a concept we call "frame locking" where they are guaranteed to
> >>> >remain in memory (i.e. not get flushed for some other memory
> >>> allocation
> >>> >request) as long as the frame is in scope. There's a macro for
> >>> >generating these lock frames called:
> >>> >
> >>> > MDLCACHE_CRITICAL_SECTION();
> >>> >
> >>> >
> >>> >If you search, you'll see these frames declared at the top
> >>> of a bunch
> >>> >of the systems (entity think, save/load, etc) So any studio headers
> >>> >that are loaded in the scope of that can't be freed until
> >>> you exit that
> >>> >scope. The assert is saying that you aren't within one of
> >>> those scopes
> >>> >so theoretically your pointer could get freed if some other memory
> >>> >request causes the cache to fill later on - so it's not safe
> >>> to hang on
> >>> >to this pointer and still call memory management functions
> >>> in datacache.
> >>> >
> >>> >It's easy enough to fix the assert by adding a frame using the macro
> >>> >above to whatever entry point is causing you to page in the model.
> >>> >Don't put one in GetModelPtr() however as that defeats the whole
> >>> >purpose of this debug instrumentation.
> >>> >
> >>> >Jay
> >>> >
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: [EMAIL PROTECTED]
> >>> >> [mailto:[EMAIL PROTECTED] On Behalf Of Aaron
> >>> >> Schiff
> >>> >> Sent: Wednesday, August 30, 2006 5:47 PM
> >>> >> To: [email protected]
> >>> >> Subject: Re: [hlcoders] AssertOnce(
> >>> pModelCache->IsFrameLocking() );
> >>> >>
> >>> >> --
> >>> >> [ Picked text/plain from multipart/alternative ] More like
> >>> a problem
> >>> >> with the calls we make to them. It seems to only show up when
> >>> >> initially showing a model...
> >>> >>
> >>> >> On 8/30/06, Ryan Sheffer <[EMAIL PROTECTED]> wrote:
> >>> >> >
> >>> >> > --
> >>> >> > [ Picked text/plain from multipart/alternative ] Im also
> >>> wondering
> >>> >> > what this is, IsFrameLocking()... Possible problem with
> >>> our models?
> >>> >> >
> >>> >> > On 8/26/06, [EMAIL PROTECTED]
> >>> >> > <[EMAIL PROTECTED]
> >>> >> > >
> >>> >> > wrote:
> >>> >> > >
> >>> >> > > AssertOnce( pModelCache->IsFrameLocking() );
> >>> >> > >
> >>> >> > > This assert is always hit, both server-side
> >>> >> baseanimating.cpp(2352)
> >>> >> > > and client-side c_baseanimating.cpp(931) when a player joins a
> >>> >> > > server. The purpose of this assert is unclear.
> >>> >> Unfortunately the
> >>> >> > > function it is asserting is closed-source with no
> >>> >> documentation on
> >>> >> > > its purpose either. I've added a KI recommending
> >>> >> commenting it out for now.
> >>>
> >>> _______________________________________________
> >>> To unsubscribe, edit your list preferences, or view the list
> >>> archives, please visit:
> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>
> >>>
> >>
> >>_______________________________________________
> >>To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> >>http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >_______________________________________________
> >To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> >http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders