I agree more documentation of the closed source API's would be nice.
On 9/3/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
There's already a MDLCACHE_CRITICAL_SECTION(); in C_BaseEntity::PostDataUpdate
that should take care of that one. Post a stack trace if you're certain you
haven't regressed that one.
At 2006/09/03 02:21 PM, Robbie Groenewoudt wrote:
>--
>[ 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: hlcoders@list.valvesoftware.com
>> >>> 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: hlcoders@list.valvesoftware.com
>> >>> >> 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
_______________________________________________
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
