|Anonymous | Login | Signup for a new account||2021-10-17 20:55 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008621||opensim||[REGION] Scripting Engine||public||2019-10-30 08:29||2020-11-19 07:35|
|Platform||PC||Operating System||Windows||Operating System Version||10|
|Product Version||master (dev code)|
|Target Version||master (dev code)||Fixed in Version||master (dev code)|
|Summary||0008621: Improvement of informaton provided for DEBUG [YEngine]: parsing errors|
|Description||YEngine is stricter on script syntax than XEngine but usually shows good error messages indicating the position of object, script name and even (line,character) information about the problem.|
But I am seeing this message without further elaboration of the object:script involved.
DEBUG [YEngine]: parsing errors on 9pL0qeW@pcYBjkQc11I1HbE0ArzcUGFCNJdvSu966l7
Can this message be enhanced to give similar object:script and location information if possible?
|Additional Information||Most YEngine script issues give good diagnostics to openSim.log with position of object and (line,character) position of the problem. E.g. the following which makes tracking down the problem easier...|
WARN [YEngine]: compile error on w6kZVnpmgf5glL@6uVJusruZkOO7WhhgL@h6Ddfjt6c (asset://49b6aa9f-5fa3-4d49-8248-1e29c249036c [^])
INFO [YEngine]: - <144.7625, 212.0385, 23.40209> ICS 02-AR48-Firefly:control
INFO [YEngine]: - (180,18) Error: Object reference not set to an instance of an object.
|Tags||No tags attached.|
|Git Revision or version number||opensim-0.9.1.1Dev-4-g5a3ba2a|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
|Attached Files||0001-Add-more-debugging-info.patch [^] (1,033 bytes) 2019-10-30 15:09 [Show Content]|
Error in question is located in: \OpenSim\Region\ScriptEngine\YEngine\MMRScriptCompile.cs line 70ff
Seeing the context of that part implementing at least the script name might be possible quite easily. Just flying over this for more may need to pull in other references.
Line 86 orig: m_log.Debug ("[YEngine]: parsing errors on " + m_ScriptObjCodeKey);
Replaced with: m_log.Debug ("[YEngine]: parsing errors on " + m_ScriptObjCodeKey + " (" + m_CameFrom + ")");
Have not tested that yet though.
|Yes YEngine error reporting needs more work, and there are messages a lot more criptic than that :)|
edited on: 2019-10-30 12:55
Thanks Tampa. I may make a custom version to track down a few issues.
The region is usually obvious from the context, but the most useful thing is the object and script name (some objects may have a lot of scripts) and helpfully the position x,y,z info.
|I added a small patch that seems to build fine with master, maybe it adds the info you are looking for... or it crashes, let me know how it goes :)|
edited on: 2019-10-31 02:36
Thanks Tampa, good of you to provde that. I tried it and do get the asset://UUID. [^] DEBUG [YEngine]: parsing errors on 9pL0qeW@pcYBjkQc11I1HbE0ArzcUGFCNJdvSu966l7 (asset://af8260d6-e808-4b76-ac2f-091670f19084 [^]
But meanwhile I have traced this through my MySQL database. It is an asset type 10 : LSL-Text, which I guess we already knew and the name is "From IAR" which is a bit vague. But I see I can open the content "BLOB" in the Windows MySQL Editor :-) So I have the contents of the faulty script now and it includes this line...
-.1.2 does not look like good LSL does it :-)
That will let me track it down. For normal users the objectname:script and x,y,z position as reported on other YEngine error and log messages would be the most useful.
As people get OpenSim 0.9.1.0 now its out they may be encouraged to try YEngine to see how it goes, so others will have transition issues I would imagine. Good diagnostics at this stage might be wise.
Having the asset uuid is a good starting point though, that can be searched in the db just like you did.
From what I can gather the part that parses this has no clue which object the script is actually it, it just does parsing, adding information to the position and objectname thus may be a bit more complex.
The patch should probably make it into master, at least then there is some info to track down issues even if it means digging through mysql :)
|That would be good. Thanks Tampa, I tracked down the glitch on my setup.|
|Change on master now should provide some more useful info :)|
|2019-10-30 08:29||aiaustin||New Issue|
|2019-10-30 09:55||tampa||Note Added: 0035805|
|2019-10-30 11:26||UbitUmarov||Note Added: 0035806|
|2019-10-30 12:55||aiaustin||Note Added: 0035807|
|2019-10-30 12:55||aiaustin||Note Edited: 0035807||View Revisions|
|2019-10-30 15:09||tampa||File Added: 0001-Add-more-debugging-info.patch|
|2019-10-30 15:10||tampa||Note Added: 0035808|
|2019-10-31 02:10||aiaustin||Note Added: 0035809|
|2019-10-31 02:16||aiaustin||Note Edited: 0035809||View Revisions|
|2019-10-31 02:17||aiaustin||Note Edited: 0035809||View Revisions|
|2019-10-31 02:20||aiaustin||Note Edited: 0035809||View Revisions|
|2019-10-31 02:34||tampa||Note Added: 0035810|
|2019-10-31 02:36||aiaustin||Note Edited: 0035809||View Revisions|
|2019-10-31 02:55||aiaustin||Note Added: 0035811|
|2020-11-19 07:35||tampa||Note Added: 0037210|
|2020-11-19 07:35||tampa||Status||new => resolved|
|2020-11-19 07:35||tampa||Fixed in Version||=> master (dev code)|
|2020-11-19 07:35||tampa||Resolution||open => fixed|
|2020-11-19 07:35||tampa||Assigned To||=> tampa|
|Copyright © 2000 - 2012 MantisBT Group|