OpenSim Core Bugs

Syndicate content MantisBT - Issues - (rdcdev)
MantisBT - Issues - (rdcdev)
Updated: 47 min 33 sec ago

0007283: Wiki should be updated to indicate that Get/Set primitive params is currently not fully implemented

Mon, 2014-07-28 17:40
For the influx of new "SL refugees" who don't watch or know to search Mantis, the Opensim Wiki page for current function status should be updated to reflect only partial implementation of the various get/set primitive params functions which do not yet support advanced materials.<br /> <br /> Page: <a href="http://opensimulator.org/wiki/LSL_Status/Functions">http://opensimulator.org/wiki/LSL_Status/Functions</a> [<a href="http://opensimulator.org/wiki/LSL_Status/Functions" target="_blank">^</a>]<br /> Functions affected:<br /> llGetLinkPrimitiveParams()<br /> llGetPrimitiveParams()<br /> llSetLinkPrimitiveParams()<br /> llSetLinkPrimitivieParamsFast()<br /> llSetPrimitiveParams()
Categories: OpenSim Bugs

0006977: Limit see and chat with avatars of others parcels do not work

Sun, 2014-07-27 13:21
In option About Land/Options/"The avatars of other parcels can see and chat with the avatars of this parcel"<br /> <br /> The box remains grayed out, it is not checkable/uncheckable.<br /> <br /> Normally it should be clickable to limit the chat and the avatar cam ... and probably too with scripts functions (llSay etc ...).<br /> <br /> Tested with Singularity, Firestrom, Kokua.<br /> <br /> NB: The voice parcel limitation work fine.
Categories: OpenSim Bugs

0006789: BulletSim: Consuming vast amounts of CPU

Sun, 2014-07-27 09:57
I have been testing BulletSim physics on a separate computer connected to our grid. Finding it stable enough, at least on 0.7.6 Dev (fc4f86a), I've decided to run it on our "main" grid (running Ubuntu 10.04 and Mono 2.10.8.1).<br /> <br /> I was astonished at the amount of CPU that this is currently consuming. Usually, I can easily run 6 instances on this old server, each with about 100.000 prims on several regions, and, when idle, CPU consumption is around 2%, peaking to 10% occasionally (e.g. when saving snapshots or doing something), but, of course, when avatars are around, the load increases when the avatar just logs in. The server has 6 GBytes of memory and rarely ever consumes more than 3-4.<br /> <br /> When switching to BulletSim, memory consumption went to twice normal (see resolved issue <a href="http://opensimulator.org/mantis/view.php?id=6599">http://opensimulator.org/mantis/view.php?id=6599</a> [<a href="http://opensimulator.org/mantis/view.php?id=6599" target="_blank">^</a>]) but CPU skyrocketed. Idle instances are routinely consuming 40-60% of all CPU — each. Which, of course, brings the server to its knees, and logging in, while it allows everything to be loaded relatively quickly, avatar movement is next to impossible.<br /> <br /> Switching back to ODE restores the server to its usual low CPU consumption.<br /> <br /> Now I understand that this might be just related to BulletSim parameters, with which I'm not familiar (yet). Maybe there is a recommended set of parameters to keep CPU consumption as low as under ODE?
Categories: OpenSim Bugs

0006496: BulletSim -- Collision events not being activated all the time when prims collide with bullets.

Sat, 2014-07-26 23:12
When bullets are fired at the face of a prim some go through and some bounce off, in both the go through case and the bounce off case getting a collision_start and collision event activated is rare.
Categories: OpenSim Bugs

0007226: [PATCH]Bulletsim-- Implement Vehicle Reference Frame.

Sat, 2014-07-26 23:11
This has not been working before but this small tweak allows you to use it for vehicles.
Categories: OpenSim Bugs

0007147: Texture offset does not work properly in a linkset

Sat, 2014-07-26 19:53
Texture offset work perfectly in a single prim but doesn't work properly in a linkset.<br /> <br /> Tested with:<br /> <br /> llOffsetTexture<br /> osSetPrimitiveParams<br /> llSetPrimitiveParams<br /> llSetLinkPrimitiveParamsFast
Categories: OpenSim Bugs

0006855: [SCRIPT] llDetectedLinkNumber broken with collision in a link set

Sat, 2014-07-26 11:45
llDetectedLinkNumber don't work with collision event in a link set ...<br /> That work fine in SL, i have tested with the script below.
Categories: OpenSim Bugs

0007157: llGetAgentLanguage(llDetectedKey(0)) return always en-us

Sat, 2014-07-26 11:44
llGetAgentLanguage(llDetectedKey(0)) return always en-us with singularity (and with Firestorm too)
Categories: OpenSim Bugs

0006880: Print Notecard on Prim (MOAP)

Sat, 2014-07-26 11:43
I tried several methods to display the contents of a notecard on a prim with MOAP<br /> <br /> - Direct printing<br /> - With Javascript and HTML<br /> - With RequestURL and display html page<br /> - Change Chartset (iso and utf-8)<br /> <br /> After all these tests I still see the same problem, special characters are not displayed correctly (é, à, è, ...).<br /> <br /> I think Opensim do not like the French ...<br /> <br /> Thank you in advance.
Categories: OpenSim Bugs

0007209: [Script] PRIM_OMEGA return no values

Sat, 2014-07-26 11:36
PRIM_OMEGA return no values.<br /> <br /> Tested with:<br /> llGetPrimitiveParams([PRIM_OMEGA]);<br /> <br /> and with:<br /> llGetLinkPrimitiveParams(LINK_ROOT, [PRIM_OMEGA]);
Categories: OpenSim Bugs

0007214: [SCRIPT] PRIM_MEDIA_AUTO_PLAY TRUE does not work with llSetLinkMedia

Sat, 2014-07-26 11:36
I see PRIM_MEDIA_AUTO_PLAY, TRUE does not work when I use it in the llSetLinkMedia function. I have to click a second time to display the content. The content is not displayed automatically.
Categories: OpenSim Bugs

0007273: Territory conflicts with varregions

Fri, 2014-07-25 21:48
If a person uses the north east coordinate of your var region to put their new regular region it trumps your var and gives that corner to the interloper (even tho your var was up and running) rendering the whole var unreachable, you can however tp to the unwary squatters region and see it's name on the map, etc.<br /> <br /> One reason this happens is the Grid map on the website shows varregions as one regular 256 region instead of it's real 768, 1024 etc size. We need the grid map fixed to avoid the conflict but more important than that we need to prevent people from setting up on coordinates that are already in use.
Categories: OpenSim Bugs

0007276: Can no longer login direct, or HG to a variable-sized (>256) region.

Tue, 2014-07-22 13:22
Issue with commit r/24977 (3c6bec)'On login and first HG entrance to a foreign grid, perform query access checks before proceeding.'<br /> <br /> Attempt login or HG teleport to a variable-sized-region (larger than 256) fails with Viewer Dialogue: 'Teleport failed. Destination is a variable-sized region, and source is an old simulator. Consider upgrading.'<br /> <br /> Teleport to a variable-sized region within the same grid does not exhibit this issue.
Categories: OpenSim Bugs

0007274: Users added to parcel & estate ban list are still able to go to a var and stay as long as they want. Have not tested on non var

Tue, 2014-07-22 03:47
Users that have been added to both the parcel and estate ban lists can still enter into the var area with no problem and stay as long as they like. I assume the ban list is supposed to work on a var, but it appears to not be working.
Categories: OpenSim Bugs

0007230: Teleport into SW 256x256 area of a var causes terrain to load reverse order than normal.

Tue, 2014-07-22 02:45
When I teleport into a var region and the var has the landing point set to the far SW sim 256x256 area, the terrain starts loading with the far NE corner of the var first and loads the spot where the AV is standing last. This is reverse of what it should be doing. If the AV flies to the center of the var and logs off, then logs back in to the last location in the var middle, the terrain loads correctly starting at the spot where the av is located and out from there. The load order is hard to see on really fast connections.<br /> <br /> This is repeatable 100% of the time under these conditions with SendTerrainUpdatesByViewDistance = true
Categories: OpenSim Bugs

0007270: Exception when contacting presence server (not enough free sockets?)

Mon, 2014-07-21 23:29
This might not be strictly a bug, but merely a configuration issue — either at the OS level or at the ROBUST/simulator level.<br /> <br /> I've noticed that in a region that makes frequent HTTP calls, at some point, the server starts throwing exceptions, both on outgoing calls, as well as HTTP calls to the ROBUST server. As a result, the region stops responding as it needs HTTP calls for some critical functions. Moving around, as long as no HTTP calls are needed, still works.<br /> <br /> This hasn't been easy to pinpoint. Typical errors occur only after several hours (and probably thousands of HTTP calls). Here is a sample (my.robust.server.tld is a fake name for the purposes of this log):<br /> <br /> 2014-07-16 14:29:39,218 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:29:39,218 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:29:49,318 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP cf6ca37f-6cbd-4039-9d70-58a2919f7322 in prim My Online Status Indicator, localID 2267576109, timeout was 100 ms<br /> 2014-07-16 14:29:49,320 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:29:49,321 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:30:39,432 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP 03a9b966-0320-41df-bba6-2663a69b36c8 in prim My Online Status Indicator 2, localID 2267576108, timeout was 100 ms<br /> 2014-07-16 14:30:39,434 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:30:39,435 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:30:49,534 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP cf6ca37f-6cbd-4039-9d70-58a2919f7322 in prim My Online Status Indicator, localID 2267576109, timeout was 100 ms<br /> 2014-07-16 14:30:49,535 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:30:49,537 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:31:39,636 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP 03a9b966-0320-41df-bba6-2663a69b36c8 in prim My Online Status Indicator 2, localID 2267576108, timeout was 100 ms<br /> <br /> While the above logs seem to be limited specifically to presence calls, this is not the case. Objects routinely making external HTTP calls will be affected as well. At some point, the simulator will prevent them from make any further calls and shut the scripts down. The above errors come mostly from an in-world script which was not aborted for some reason.<br /> <br /> A few tests have been made to try to isolate this issue. The first change involved tweaking several parameters at the OS level. Current sysctl.conf is:<br /> <br /> net.ipv4.conf.default.rp_filter = 1<br /> net.ipv4.conf.all.rp_filter = 1<br /> net.ipv4.tcp_syncookies = 1<br /> net.ipv4.conf.all.send_redirects = 0<br /> net.ipv4.conf.all.accept_source_route = 0<br /> net.ipv6.conf.all.accept_source_route = 0<br /> net.ipv6.conf.all.autoconf = 0<br /> net.ipv6.conf.default.autoconf = 0<br /> net.ipv6.conf.eth0.autoconf = 0<br /> net.ipv6.conf.all.accept_ra = 0<br /> net.ipv6.conf.default.accept_ra = 0<br /> net.ipv6.conf.eth0.accept_ra = 0<br /> net.core.rmem_default = 524288<br /> net.core.rmem_max = 16777216<br /> net.core.wmem_default = 524288<br /> net.core.wmem_max = 16777216<br /> net.ipv4.tcp_max_syn_backlog = 2048<br /> net.ipv4.tcp_rmem = 10240 87380 16777216<br /> net.ipv4.tcp_wmem = 10240 87380 16777216<br /> net.ipv4.tcp_no_metrics_save = 1<br /> net.ipv4.tcp_mem = 524288 524288 524288<br /> net.ipv4.tcp_rfc1337 = 1<br /> net.ipv4.ip_no_pmtu_disc = 0<br /> net.ipv4.tcp_sack = 1<br /> net.ipv4.tcp_fack = 1<br /> net.ipv4.tcp_window_scaling = 1<br /> net.ipv4.tcp_timestamps = 1<br /> net.ipv4.tcp_ecn = 0<br /> net.ipv4.route.flush = 1<br /> fs.file-max = 2097152<br /> vm.swappiness = 10<br /> vm.dirty_ratio = 60<br /> vm.dirty_background_ratio = 2<br /> net.ipv4.tcp_synack_retries = 2<br /> net.core.somaxconn = 65535<br /> net.core.netdev_max_backlog = 65536<br /> net.core.optmem_max = 25165824<br /> net.ipv4.udp_mem = 65536 131072 262144<br /> net.ipv4.tcp_max_tw_buckets = 1440000<br /> net.ipv4.tcp_tw_recycle = 1<br /> net.ipv4.tcp_tw_reuse = 1<br /> <br /> (based on several suggestions, including <a href="https://rtcamp.com/tutorials/linux/sysctl-conf/">https://rtcamp.com/tutorials/linux/sysctl-conf/</a> [<a href="https://rtcamp.com/tutorials/linux/sysctl-conf/" target="_blank">^</a>])<br /> <br /> The server in question has lots of spare memory, thus creating larger buffers, more sockets, and diminishing swapping is perfectly acceptable. It runs ROBUST, 6 simulator instance (running some 20 regions), and nginx + php5-fpm + MySQL, and still only consumes about 3 out of 6 GBytes of RAM.<br /> <br /> A few optimizations have been made. The first was to ensure that all scripts who use outgoing calls release acquired URLs (e.g. call llReleaseURL() if a URL acquired via llRequestURL() is not needed any more). This substantially improved, but not removed, the issue. Then possible timeouts calling the nginx server (which runs not only several external modules for the core services, but also a complex application which several in-world items contact frequently) were investigated; nginx was using a Unix socket configuration to communicate with php5-fpm (good for low-traffic solutions), and this was moved to a more standard TCP socket communication instead (which allegedly is better for dealing with high-traffic solutions). While this is by no means an exhaustive way of eliminating any issues on the operating system side, it was important for me to make sure that the problem is not simply a bad server configuration.<br /> <br /> When the application is fully operational, this results in (possibly) hundreds of HTTP calls per minute, made from several in-world objects, some running inside avatar attachments on NPCs. Hitting internal limits is a strong possibility, but it would be expected that some console errors would pop up (e.g. alerts about culling the amount of HTTP calls being made). However, this is not the case. Objects which merely contact a webserver once per minute, left running several hours, will start throwing the aforementioned errors.<br /> <br /> It's unclear if the errors happen at the ROBUST side as well as at the simulator side. ROBUST doesn't throw any errors, neither at the console level, nor at the logging level. Nevertheless, the simulator complains about not being able to contact ROBUST. This seems to be strictly tied to the single simulator running those objects making HTTP calls; other simulator instances do not show any errors.<br /> <br /> OpenSim.ini has the following network- and script-related configurations:<br /> <br /> [ClientStack.LindenUDP]<br /> client_socket_rcvbuf_size = 12582912<br /> AckTimeout = 180<br /> <br /> [XEngine]<br /> Enabled = true<br /> MinThreads = 2<br /> MaxThreads = 100<br /> IdleTimeout = 60<br /> Priority = "BelowNormal"<br /> MaxScriptEventQueue = 300<br /> ThreadStackSize = 262144<br /> AppDomainLoading = true<br /> DeleteScriptsOnStartup = true<br /> DefaultCompileLanguage = "lsl"<br /> AllowedCompilers = "lsl,cs,js,vb"<br /> CompileWithDebugInformation = true<br /> AllowMODFunctions = false<br /> AllowOSFunctions = true<br /> AllowLightShareFunctions = true<br /> OSFunctionThreatLevel = Low<br /> EventLimit = 30<br /> KillTimedOutScripts = false<br /> ScriptDelayFactor = 1.0<br /> ScriptDistanceLimitFactor = 1.0<br /> SensorMaxRange = 96.0<br /> SensorMaxResults = 16<br /> <br /> Simulators are also checked for 'health' via monit, by calling <a href="http://localhost:XXXX/jsonSimStats/">http://localhost:XXXX/jsonSimStats/</a> [<a href="http://localhost:XXXX/jsonSimStats/" target="_blank">^</a>] (XXXX varies for each instance) every cycle. WebStats are also enabled.<br /> <br /> Currently, my 'prime suspect' is an object that checks if an avatar is online every minute and sends the reply to an external webserver. Similar scripts abound in Second Life (where I have some of them running for 7 or 8 years...), and I have been running them on OpenSimulator for a couple of years at least. It's only on the latest versions (0.8.0 Dev) that I have encountered this issue.<br /> <br /> While this might not be an OpenSimulator 'bug' (I kept the severity as minor and priority as low on this report), but merely a misconfiguration of either ROBUST, OpenSim.ini, or the underlying server, any help in fixing this might be useful in the future for anyone who might have the same problem.
Categories: OpenSim Bugs

0007275: [XBakes] read, store, read, store, read for unchanged avatar on every login

Mon, 2014-07-21 15:29
With improved XBakes console logging in r/24973 (for example) for each avatar login - not just the first time - I see the expected read followed immediately by TWO further store/read cycles on the baked textures. I would expect just a SINGLE read I would think? No change at all has taken place, no other avatars on the test grid, and the relog attempt immediately followed a log off.<br /> <br /> 15:00:56 - [XBakes]: read 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:56 - [AVFACTORY]: Received texture update for Ai Austin e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:56 - [XBakes]: stored 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:57 - [XBakes]: read 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> <br /> 15:00:58 - [AVFACTORY]: Received texture update for Ai Austin e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:58 - [XBakes]: stored 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:58 - [XBakes]: read 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> <br /> <br /> Tested on default ./bakes directory and custom directory.
Categories: OpenSim Bugs

0007067: Avatars highly distanced from the ground

Mon, 2014-07-21 12:34
Avatars appear to float much higher above the ground than they should. Even when wearing multiple shapes, my feet are way above the floor of a simple cube. For some reason, avatar collisions might not be properly detected. Screenshot attached.
Categories: OpenSim Bugs

0007063: xbakes Robust.[HG].ini.example BaseDirectory = "/data/bakes" issue

Mon, 2014-07-21 12:33
When xbakes was added.. the example given in Robust.ini.example and Robust.HG.ini.example for the BaseDirectory used a non-standard area that is set to a root (/) based file. I assume this is not usual and probably only relevant for Unix users?<br /> <br /> [BakedTextureService]<br /> LocalServiceModule = "OpenSim.Server.Handlers.dll:XBakes"<br /> ;; This directory must exist and be writable for the user ROBUST runs as<br /> ; BaseDirectory = "/data/bakes"<br /> <br /> I think that should be "./data/bakes" or just "./bakes"? i.e. its relative to be below "bin" as is usual for all sorts of such caches and maptiles, etc.<br /> <br /> Also... I am not sure if the directory has to pre-exist as the comment implies or if its created when not already there... which is usual for such things in OpenSim.
Categories: OpenSim Bugs

0007023: Warp3d errors when (RenderMeshes = true) in [Map] section of OpenSim.ini

Mon, 2014-07-21 12:02
when RenderMeshes = true is set in [Map] section of OpenSim.ini I get the following spew on region startup<br /> <br /> 12:51:30 - Failed to decode mesh asset: Could not load type 'zlib.ZOutputStream' from assembly 'zlib.net, Version=1.0.3.0, Culture=neutral, PublicKeyToken=47d7877cb3620160'.<br /> <br /> and no mesh objects render on tiles, they just appear as a cut and hollow cube.
Categories: OpenSim Bugs