Discussion:
[hlcoders] [Base 2013 SDK / Stock Prerelease 2013 SDK] VPhysics Bug - Assured vphysics.dll hang/crash when physics objects enter specific area in a map
Peter McKeown
2016-02-29 22:52:49 UTC
Permalink
Hi everyone (and hopefully Valve),


I've been trying to track a strange crash and heap corruption issue in my mod, the problem only manifested itself after re-enabling the player's physics shadow. The problem is only reliably able to be produced in one area in a certain map, I put this down to heap corruption, but on a hunch I tested the same area in a fresh SDK mod using the prerelease beta and the same issue occurs - the stack trace always ends in vphysics.dll .


https://dl.dropboxusercontent.com/u/9880670/minimalism_crashzone.jpg

[https://dl.dropboxusercontent.com/u/9880670/minimalism_crashzone.jpg]


The hang / crash happens under the following circumstances:

* The player activates noclip and then flies into the crash sphere, and then deactivates noclip while inside it. The crash is caused by the player's physics shadow.
* A large physics object such as the airboat enters the large physics crash zone near the sphere.
* A small physics object moves near the sphere. I tested this by placing a physics object with prop_physics_create on a block next to the sphere, it rested there fine. I pushed it towards the sphere and the literal instant it moved, the game froze.
* Simply moving in that area with an active physics shadow has a chance to crash the game, sometimes the crash occurs due to heap corruption.

I'm almost certainly sure it's not an issue with map entities. I deleted all map entities such as triggers and func_ entities to be sure. One thing that may be responsible is that this map was compiled for use in SDK Base 2006. The issue appears to happen on other maps too, but I haven't been able to reproduce it. The other affected maps may also be SDK 2006 maps. Apart from this, the maps function completely fine.


This is the map that causes the crash. I can upload crash dumps if Valve need them, but it should be possible to reproduce the crash as the issue happens with the stock SDK.

https://dl.dropboxusercontent.com/u/9880670/kz_bhop_minimalism.bsp


Hopefully the problem can be resolved without changes to the SDK code. If so, please update the standard SDK vphysics as well as the prerelease one - many modders, myself included, are avoiding updating to the latest SDK because of not wanting to inconvenience players by having to switch to the SDK beta, and that problem is compounded if they have many mods where some use the beta and some don't. The best solution would be to have a Source SDK Base 2016, this would make it a matter of simply changing the appid in gameinfo.txt to get players on the right engine version.


Hopefully you see this and can fix the issue!


Regards,


Peter


_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Ryan Kistner
2016-03-02 01:58:57 UTC
Permalink
Hello Peter,

Tracing your crash puts me in
IVP_Mindist_Minimize_Solver::p_minimize_PP(IVP_Compact_Edge const*,
IVP_Compact_Edge const*, IVP_Cache_Ledge_Point*,
IVP_Cache_Ledge_Point*), which is far enough into IVP to suggest a
corrupt physics state or unsolvable interaction. In this case, I believe
the physics mesh from the displacement sphere is the source of the problem:

https://dl.dropboxusercontent.com/u/759758/kz_displacement_sphere2.jpg

I can't seem to rebuild a map with the same broken physics though. You
can confirm that Things Are Bad by setting phys_timescale 0 and trying
to walk around in the sphere area, you will collide with the mesh
sphere, confirming that it is indeed a physics mesh in play.


On 2/29/2016 3:52 PM, Peter McKeown wrote:
> Hi everyone (and hopefully Valve),
>
>
> I've been trying to track a strange crash and heap corruption issue in my mod, the problem only manifested itself after re-enabling the player's physics shadow. The problem is only reliably able to be produced in one area in a certain map, I put this down to heap corruption, but on a hunch I tested the same area in a fresh SDK mod using the prerelease beta and the same issue occurs - the stack trace always ends in vphysics.dll .
>
>
> https://dl.dropboxusercontent.com/u/9880670/minimalism_crashzone.jpg
>
> [https://dl.dropboxusercontent.com/u/9880670/minimalism_crashzone.jpg]
>
>
> The hang / crash happens under the following circumstances:
>
> * The player activates noclip and then flies into the crash sphere, and then deactivates noclip while inside it. The crash is caused by the player's physics shadow.
> * A large physics object such as the airboat enters the large physics crash zone near the sphere.
> * A small physics object moves near the sphere. I tested this by placing a physics object with prop_physics_create on a block next to the sphere, it rested there fine. I pushed it towards the sphere and the literal instant it moved, the game froze.
> * Simply moving in that area with an active physics shadow has a chance to crash the game, sometimes the crash occurs due to heap corruption.
>
> I'm almost certainly sure it's not an issue with map entities. I deleted all map entities such as triggers and func_ entities to be sure. One thing that may be responsible is that this map was compiled for use in SDK Base 2006. The issue appears to happen on other maps too, but I haven't been able to reproduce it. The other affected maps may also be SDK 2006 maps. Apart from this, the maps function completely fine.
>
>
> This is the map that causes the crash. I can upload crash dumps if Valve need them, but it should be possible to reproduce the crash as the issue happens with the stock SDK.
>
> https://dl.dropboxusercontent.com/u/9880670/kz_bhop_minimalism.bsp
>
>
> Hopefully the problem can be resolved without changes to the SDK code. If so, please update the standard SDK vphysics as well as the prerelease one - many modders, myself included, are avoiding updating to the latest SDK because of not wanting to inconvenience players by having to switch to the SDK beta, and that problem is compounded if they have many mods where some use the beta and some don't. The best solution would be to have a Source SDK Base 2016, this would make it a matter of simply changing the appid in gameinfo.txt to get players on the right engine version.
>
>
> Hopefully you see this and can fix the issue!
>
>
> Regards,
>
>
> Peter
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
>


_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Peter McKeown
2016-03-02 06:45:22 UTC
Permalink
Hi Ryan,

I can confirm that the issue doesn't appear if that sphere is recompiled on the latest build tools. I can only hope that the issue is due to the older engine the map was compiled for, your findings do make me confident enough that it's hopefully a one-off with the map.

In my attempts to discover the cause, I managed to prevent the issue if I either disabled the physics shadow (thus there was no interaction at the physics engine level), or removed any velocity for the physics object. Like you said as well, phys_timescale also prevents it. These factors do imply a solver issue. I'll just have to disable the physics shadow in this one map to prevent the issue (as it's a custom map made by a player and the original author may be unable or unwilling to recompile it) and attempt to prevent server ops from spawning physics objects into the map.

If maps are simply played in a SDK2013 mod that were compiled for the older engine and this crash occurs, it may still indicate a bug in the physics engine for those with the power to fix it. It would be best for collision detection to fail rather than crash like this. For me though, I seem to have a way forward now.

Thanks a lot for your help!

Best regards :)

Peter

________________________________________
From: hlcoders-***@list.valvesoftware.com <hlcoders-***@list.valvesoftware.com> on behalf of Ryan Kistner <***@gmail.com>
Sent: 02 March 2016 01:58
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] [Base 2013 SDK / Stock Prerelease 2013 SDK] VPhysics Bug - Assured vphysics.dll hang/crash when physics objects enter specific area in a map

Hello Peter,

Tracing your crash puts me in
IVP_Mindist_Minimize_Solver::p_minimize_PP(IVP_Compact_Edge const*,
IVP_Compact_Edge const*, IVP_Cache_Ledge_Point*,
IVP_Cache_Ledge_Point*), which is far enough into IVP to suggest a
corrupt physics state or unsolvable interaction. In this case, I believe
the physics mesh from the displacement sphere is the source of the problem:

https://dl.dropboxusercontent.com/u/759758/kz_displacement_sphere2.jpg

I can't seem to rebuild a map with the same broken physics though. You
can confirm that Things Are Bad by setting phys_timescale 0 and trying
to walk around in the sphere area, you will collide with the mesh
sphere, confirming that it is indeed a physics mesh in play.


On 2/29/2016 3:52 PM, Peter McKeown wrote:
> Hi everyone (and hopefully Valve),
>
>
> I've been trying to track a strange crash and heap corruption issue in my mod, the problem only manifested itself after re-enabling the player's physics shadow. The problem is only reliably able to be produced in one area in a certain map, I put this down to heap corruption, but on a hunch I tested the same area in a fresh SDK mod using the prerelease beta and the same issue occurs - the stack trace always ends in vphysics.dll .
>
>
> https://dl.dropboxusercontent.com/u/9880670/minimalism_crashzone.jpg
>
> [https://dl.dropboxusercontent.com/u/9880670/minimalism_crashzone.jpg]
>
>
> The hang / crash happens under the following circumstances:
>
> * The player activates noclip and then flies into the crash sphere, and then deactivates noclip while inside it. The crash is caused by the player's physics shadow.
> * A large physics object such as the airboat enters the large physics crash zone near the sphere.
> * A small physics object moves near the sphere. I tested this by placing a physics object with prop_physics_create on a block next to the sphere, it rested there fine. I pushed it towards the sphere and the literal instant it moved, the game froze.
> * Simply moving in that area with an active physics shadow has a chance to crash the game, sometimes the crash occurs due to heap corruption.
>
> I'm almost certainly sure it's not an issue with map entities. I deleted all map entities such as triggers and func_ entities to be sure. One thing that may be responsible is that this map was compiled for use in SDK Base 2006. The issue appears to happen on other maps too, but I haven't been able to reproduce it. The other affected maps may also be SDK 2006 maps. Apart from this, the maps function completely fine.
>
>
> This is the map that causes the crash. I can upload crash dumps if Valve need them, but it should be possible to reproduce the crash as the issue happens with the stock SDK.
>
> https://dl.dropboxusercontent.com/u/9880670/kz_bhop_minimalism.bsp
>
>
> Hopefully the problem can be resolved without changes to the SDK code. If so, please update the standard SDK vphysics as well as the prerelease one - many modders, myself included, are avoiding updating to the latest SDK because of not wanting to inconvenience players by having to switch to the SDK beta, and that problem is compounded if they have many mods where some use the beta and some don't. The best solution would be to have a Source SDK Base 2016, this would make it a matter of simply changing the appid in gameinfo.txt to get players on the right engine version.
>
>
> Hopefully you see this and can fix the issue!
>
>
> Regards,
>
>
> Peter
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
>


_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders


_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Asher Baker
2016-03-02 10:02:33 UTC
Permalink
On Wed, Mar 2, 2016 at 6:45 AM, Peter McKeown <***@hotmail.com>
wrote:

> it may still indicate a bug in the physics engine for those with the power
> to fix it. It would be best for collision detection to fail rather than
> crash like this.


VPhysics is unfortunately pretty consistently crashy, it could do with a
lot of love: https://crash.limetech.org/stats/vphysics.%25

~~~~~
"Their heads are green, and their hands are blue,
And they went to sea in a Sieve." - Edward Lear
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Loading...