|Anonymous | Login | Signup for a new account||2020-01-23 15:13 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005068||opensim||[REGION] Scripting Engine||public||2010-09-29 05:46||2011-07-15 18:18|
|Target Version||Fixed in Version|
|Summary||0005068: Script engine thread exception: null pointer, when there is abnormal parcel condition|
|Description||I had a transient condition in which parcel information was only partially available; subparcel boundaries were not appearing; spurious straight line parcel boundaries did appear; one could not rez/create/drop/move a prim into the subparcel even though previously one had the power to do this; one could erratically see parcel boundaries marked with selection lines; parcel names were not displayed. A region roll back corrected this problem.|
During this condition, when a script called llSetParcelMusicStream(), the script engine would issue a null-pointer exception report (see additional information). This was a repeatable behavior. Repeated calls to this function when within the 'ghost' parcel caused the exception. Several scripted objects, when calling this function, caused this exception.
This was an abnormal region condition. This exception occurred in an unexpected situation. Thus, it may be the case that no action is required to fix or prevent this exception. However, I report this as a matter of interest and for the possibility that it might cast light on another problem.
|Additional Information||-------------------------------- script engine exception report|
landmusic and media controller - os1b: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
Server stack trace:
at OpenSim.Region.ScriptEngine.Shared.Api.LSL_Api.llSetParcelMusicURL(String url) in c:\OpenSim\0.6.9\Console1\OpenSim\Region\ScriptEngine\Shared\Api\Implementation\LSL_Api.cs:line 7252
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at :
[Note that the message is cut off here.. /de]
|Tags||No tags attached.|
|Git Revision or version number||??|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
|Attached Files||0001-Avoid-System.NullReferenceException-when-it-fail-to-.patch [^] (13,650 bytes) 2011-07-09 06:58 [Show Content]|
Could you please provide the GIT or Revision ID so this can be tracked. Otherwise this won't help.
If you are building it yourself and not generating the .version file in Bin you may want to look at this link.
Desdemona Enfield (reporter)
The only information I find is as reported by the region server command show version:
"Version: OpenSim 0.6.9 (ReactionGrid) (interface version 6)"
There is no .version file in bin, or anywhere else in the opensim directory tree. I have admin access to the server, however, the binaries are built and installed by the reaction grid managers. You will have to contact them to determine what they mean by "0.6.9".
This does raise an interesting question... if "0.6.9" does not mean the same exact released source set to every build location, what is the point of having these three field version numbers?
I can't reproduce the same land situation, but if the region is in such a situation, I guess World.LandChannel.GetLandObject() return will return null, which results in the exception when it uses land object next time.
At least it is generally good coding practice to check if object exist before accessing to its property, so I'll review api implementations and create a patch for that.
The results of review:
OK(no need to fix)
I added null check to these functions implementations and made them return or return 0 if ILandObject is null. FYI, ILandObject.LandData is always created when ILandObject is instantiated, so no need to null check.
Thanks for the patch, Makopoppo. However, since the time this was filed, I don't believe we should ever return null instead of a land object anymore.
If this was to occur, I would rather than we fixed the underlying code rather than ignoring the issue with a null check.
|2010-09-29 05:46||Desdemona Enfield||New Issue|
|2010-09-29 05:46||Desdemona Enfield||Git Revision||=> ??|
|2010-09-29 05:46||Desdemona Enfield||SVN Revision||=> 0|
|2010-09-29 05:46||Desdemona Enfield||Run Mode||=> Grid (Multiple Regions per Sim)|
|2010-09-29 05:46||Desdemona Enfield||Physics Engine||=> Other|
|2010-09-29 05:46||Desdemona Enfield||Environment||=> .NET / Windows64|
|2010-09-29 05:46||Desdemona Enfield||Mono Version||=> Other|
|2010-09-29 05:55||WhiteStar||Note Added: 0016908|
|2010-09-29 16:22||Desdemona Enfield||Note Added: 0016909|
|2011-07-09 05:07||makopoppo||Note Added: 0018800|
|2011-07-09 05:07||makopoppo||Status||new => acknowledged|
|2011-07-09 06:58||makopoppo||File Added: 0001-Avoid-System.NullReferenceException-when-it-fail-to-.patch|
|2011-07-09 07:03||makopoppo||Note Added: 0018801|
|2011-07-09 07:03||makopoppo||Status||acknowledged => patch included|
|2011-07-15 18:18||justincc||Note Added: 0018903|
|2011-07-15 18:18||justincc||Status||patch included => patch feedback|
|Copyright © 2000 - 2012 MantisBT Group|