Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008397opensim[REGION] OpenSim Corepublic2018-10-18 19:392018-10-25 19:42
ReporterSnootsDwagon 
Assigned To 
PriorityurgentSeveritycrashReproducibilityrandom
StatusnewResolutionopen 
PlatformOSOS Version
Product Version0.9.0.1 
Target VersionFixed in Version 
Summary0008397: osTeleportAgent() and gth causes "teleport failure" and crash
DescriptionAt random, unpredictable times using the gth command (go to height) will result in the response "Teleport Failed"... and all avatar movement on the region freezes thereafter. The region has to be completely shut down and restarted; I've found no other solution.





Additional Information[edit]: This report is updated to include osTeleportAgent() as a trigger. This was witnessed by three avatars simultaneously when ONE avatar triggered osTeleportAgent(). It froze movement on the entire region (indicating this is not a viewer-based issue), forced all three avatars to teleport elsewhere (upon which two of the avatars subsequently crashed) and required SHUTDOWN and restart of the region to fix the failed state.
TagsNo tags attached.
Git Revision or version number
Run Mode Standalone (Multiple Regions)
Physics EngineBulletSim
EnvironmentMono / Windows
Mono VersionNone
ViewerFirestorm
Attached Filespng file icon Teleport Failed. Internal Error..png [^] (511,198 bytes) 2018-10-22 11:49

- Relationships

-  Notes
(0033178)
BillBlight (developer)
2018-10-18 19:41
edited on: 2018-10-18 19:47

gth is a viewer side macro ...

Can't replicate


https://youtu.be/MFuGTronEwM [^]

(0033179)
SnootsDwagon (reporter)
2018-10-18 20:35

Since this is a "random" bug, attempting to replicate is irrelevant. It's happened more than once or I wouldn't be reporting it.

gth may be a viewer-side macro... but it's causing problems with the Opensim server. When this occurs I log out and back in... and the problem is still active, indicating something in Opensim is frozen by this action.
(0033182)
Luisillo_Contepomi (reporter)
2018-10-19 08:50
edited on: 2018-10-19 08:57

What viewer are you using? and you report that is "causing problems with the Opensim server" please include in report the alert on your region console.

Can't replicate with Singularity Viewer 1.8.7(6861) 64-bit or Firestorm 5.1.7.55786 (Firestorm-Releasex64 64bit) over opensim 0.9.0.1dev

(0033183)
SnootsDwagon (reporter)
2018-10-19 09:32
edited on: 2018-10-19 09:39

Luisillo, with all respect, "Can't replicate" doesn't solve the problem. From what I understand you are testing on a limited-use, self-server system rather than standard user-experience grids. You post "Can't replicate" repeatedly on these Mantis reports-- even when an issue is reported as random (meaning not easily replicated)... or so common they are widely recognized as issues (such as texture rezzing issues, which is a very common experience).

This is not helpful in tracking down such issues. I recognize you personally can't replicate them in your high-power, limited-impact environment. That does not mean they don't happen outside that environment.

I am using the latest Firestorm release viewer on the latest Opensim release, tied in to the OSgrid system. That is a "common-use testing ground" far more realistic for everyday use. This problem doesn't happen often, but when it does it requires shutdown of the region and rebooting; nothing else solves the problem.

Since the region console unfortunately does not include copy/paste functions that are compatible with Windows, it's very difficult to post region reports. This is especially the case when such reports comprise screens of information. Trying to locate and pull that information from .log files is like hunting a needle in a haystack-- taking it for granted that the everyday user can even undertand those files and discern what needs reported and what is irrelevant to the issue.

I'm a user. I've reported the bug and its effects. Beyond that... I don't code the software. "Can't replicate" doesn't get bugs fixed. Checking code gets bugs fixed.

(0033184)
BillBlight (developer)
2018-10-19 09:48

First of YES you can copy and paste from any region console, windows or linux, second I am testing on a standard grid.

I have tried to replicate your issue on 13 regions of my own grid and several regions on osgrid.

Also a bug by definition is replicate-able and repeatable by multiple people, this sounds like an issue with your viewer.
(0033185)
SnootsDwagon (reporter)
2018-10-19 10:14
edited on: 2018-10-22 11:21

Watcher... how do you copy from your region console to Windows? I'd enjoy knowing that method, as standard copy/paste functions don't seem to work.

I find "the problem is an issue with your viewer" when we're using the SAME viewer to be an unlikely conclusion... and one that discards the statement I've made twice now that the region remains affected even after logging out and logging back in. The only solution is to shutdown and re-start the region.... which fixed the problem.

That solution is not only totally separate from the viewer (thus eliminating the viewer as a likely problem), it points directly at Opensim code hanging up. "Failure to teleport" (to my knowledge) is not a viewer response-- it is reported from system status. I'm not totally counting out the viewer as a possibility (I've see stranger things), just pointing out that logically it's unlikely to be the viewer.

And yeah, would like to know how to copy/paste from the Opensim console to Windows, please.

(0033186)
BillBlight (developer)
2018-10-19 10:18
edited on: 2018-10-19 10:23

https://youtu.be/ddYt6r2g3lA [^]


Fine I'll be on Lbsa Plaza in about 10 minutes as Bill Blight


google is your friend ..

https://www.laptopmag.com/articles/how-to-windows-10-command-prompt-copy [^]

(0033187)
BillBlight (developer)
2018-10-19 10:25

we can goto one of the sandboxes that does not have tp forced
(0033188)
SnootsDwagon (reporter)
2018-10-19 10:26

Neat YouTube Watcher. You evidently accomplished the goal. What the video didn't show is HOW you did it. Is that a standard command console... and what did you do within that console to get that information to copy over?

Standard copy/paste commands don't work on my Windows 10 system. It is typical in all versions of Windows that DOS/shell windows do not copy/paste to Windows 10. So something is different on your system than most others. Can't help but wonder what it is. Would love to find out.
(0033189)
SnootsDwagon (reporter)
2018-10-19 10:32
edited on: 2018-10-22 11:23

Thanks for the info Watcher. Testing it out now. A few hoops to jump through that aren't obvious... but typical. And yeah... just tested, didn't work. Yaaay Microsoft, turning yet another simple concept into a mess. ;D

And sorry, I don't have time to right now to do a test on a highly-random occurrence. You test it and let me know what happens in testing an intermittent bug. ; )

(0033190)
SnootsDwagon (reporter)
2018-10-19 10:33

Follow-up: try it at all heights, every 1000m or so. Seems to happen more often at 4000m or above.
(0033191)
BillBlight (developer)
2018-10-19 10:38

While waiting I went to several sandboxes and one fairly populated (12) region and tested and could not make it happen ..


There are many things system side , corrupt installs, bad files, even a corrupt cache that can cause an individuals viewer to crash .. This does not always point to an issue with opensimulator code ..

and yes that is a standard command console

Left click the upper right corner
goto defaults and make sure quick edit mode is checked , not knowing how to do something does not mean it is broken.

Nothing special about my install standard windows 10
(0033192)
SnootsDwagon (reporter)
2018-10-19 10:41

Well, finally figured it out Watcher. Standard Ctrl-C didn't work; had to use Ctrl-Ins to copy. Why? No idea. It's Micro$oft.

But thanks... now that bit of info is at my disposal. Greatly appreciated.
(0033194)
SnootsDwagon (reporter)
2018-10-19 12:17
edited on: 2018-10-20 20:45

Luisillo was very kind to visit me today at ElvenSong and we had a nice chat about how OSgrid / Opensim / Asset Servers / Firestorm works. She helped me to realize I need to report these kinds of issues on OSgrid rather than Opensim. (I had thought this was the OSgrid Mantis. oops).

She was quite nice and took time to explain to me how the four items work together, and why it can be so difficult to track down bugs. It seems that some of the bugs I've been reporting here are indeed legitimate bugs, but are more likely due to asset server issues than problems with Opensim.

That doesn't mean it isn't a "joint problem"... just that i need to report it to the proper area (OSgrid) so they can figure out where the bug originates.

Got it! Please excuse... been on virtual worlds for a looong time, but rather new to the Opensim / Robust / OSgrid / Hypergrid area. Almost like being a newb again, trying to figure out things I never had to tackle in a closed grid. Far more freedom here... and the learning curve just went UP! mwahahahahhaa

Thank you for your patience.

(0033195)
BillBlight (developer)
2018-10-19 12:44

Glad you are learning ...

That is an issue, opensimulator is a complex thing, and anybody that says it isn't does not actually understand it.

Various configurations can show varying behavior that has nothing to do with the software but how it is setup, correctly , incorrectly or just different.

It is the greatest strength and weakness at the same time.

What may seem to be a prominent issue in one place may never show up in another.
(0033210)
SnootsDwagon (reporter)
2018-10-20 19:48
edited on: 2018-10-20 20:15

Adding to this report... because now have witnesses.

This happened tonight when two other avatars were on the region. System executed an osTeleportAgent() function... and froze all avatar movement on the entire region.

This happens both with osTeleportAgent() *and* with gth. This strongly indicates it is not a Firestorm issue (it affected all avatars on the region), it is not likely an OSgrid issue (possible but not likely)... most likely an Opensim issue.

As stated before this is a random error, making it extremely difficult to replicate. But now I have two witnesses that it actually happened.

The bad part: the only way I have found to fix this issue is to totally SHUTDOWN and re-start the entire region. A regular restart does not work... and does not re-initialize scripts properly.

That makes this bug a MAJOR SYSTEM CRASH AND BLOCK issue.

(0033211)
Koni Lanzius (reporter)
2018-10-20 19:51

yea the whole sim frooze , we couldn't walk. I can can verify it stopped all movement on the region
~Koni
(0033212)
John Sunekova (reporter)
2018-10-20 20:23

All 3 of us were not able to move, the TP's didn't work within the region since the region was frozen, however, we were able to teleport out to a nearby region where all was normal. The region had to be forced to shutdown simply by closing the simulator, and only then it could be restarted.
(0033213)
SnootsDwagon (reporter)
2018-10-20 20:30
edited on: 2018-10-20 20:47

As an addition to this report: this problem is caused by both gth *and* osTeleportAgent().

Upon execution of osTeleportAgent() for myself, all three avatars froze. We were unable to move or teleport within the region.

All three of us were able to teleport out of the region and to another successfully. Very shortly following the teleport however, both John and I crashed (Koni didn't), and we crashed at about the same moment. Indication while watching the server is that we crashed when the server shut down-- indicating a carry-over effect from the other region (even following successful teleport).

Here is a copy of the Opensim log directly following the osTeleportAgent() call:

22:19:01 - [ENTITY TRANSFER MODULE]: Teleport for Snoots Dwagon to <794, 998, 3518> within ElvenSong
22:19:01 - [ENTITY TRANSFER MODULE]: Exception on teleport of Snoots Dwagon from <794, 998, 3518>@ElvenSong to <794, 998
, 3518>@ElvenSong: Object reference not set to an instance of an object. at OpenSim.Region.PhysicsModule.BulletS.BSAPI
Unman.SetLinearVelocity(BulletBody obj, Vector3 vel) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\OpenSim\Region\PhysicsMod
ules\BulletS\BSAPIUnman.cs:line 1219
   at OpenSim.Region.PhysicsModule.BulletS.BSCharacter.set_ForceVelocity(Vector3 value) in k:\OSGRID\opensim-0.9.0.1-468
-g235dd37\OpenSim\Region\PhysicsModules\BulletS\BSCharacter.cs:line 509
   at OpenSim.Region.PhysicsModule.BulletS.BSPhysObject.<set_Velocity>b__1() in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\O
penSim\Region\PhysicsModules\BulletS\BSPhysObject.cs:line 273
   at OpenSim.Region.PhysicsModule.BulletS.BSScene.TaintedObject(String pOriginator, String pIdent, TaintCallback pCallb
ack) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\OpenSim\Region\PhysicsModules\BulletS\BSScene.cs:line 1244
   at OpenSim.Region.PhysicsModule.BulletS.BSScene.TaintedObject(UInt32 pOriginator, String pIdent, TaintCallback pCallb
ack) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\OpenSim\Region\PhysicsModules\BulletS\BSScene.cs:line 1233
   at OpenSim.Region.PhysicsModule.BulletS.BSPhysObject.set_Velocity(Vector3 value) in k:\OSGRID\opensim-0.9.0.1-468-g23
5dd37\OpenSim\Region\PhysicsModules\BulletS\BSPhysObject.cs:line 271
   at OpenSim.Region.PhysicsModule.BulletS.BSCharacter.set_Velocity(Vector3 value) in k:\OSGRID\opensim-0.9.0.1-468-g235
dd37\OpenSim\Region\PhysicsModules\BulletS\BSCharacter.cs:line 488
   at OpenSim.Region.PhysicsModule.BulletS.BSPhysObject.SetMomentum(Vector3 momentum) in k:\OSGRID\opensim-0.9.0.1-468-g
235dd37\OpenSim\Region\PhysicsModules\BulletS\BSPhysObject.cs:line 283
   at OpenSim.Region.PhysicsModule.BulletS.BSCharacter.SetMomentum(Vector3 momentum) in k:\OSGRID\opensim-0.9.0.1-468-g2
35dd37\OpenSim\Region\PhysicsModules\BulletS\BSCharacter.cs:line 500
   at OpenSim.Region.Framework.Scenes.ScenePresence.TeleportWithMomentum(Vector3 pos, Nullable`1 v) in k:\OSGRID\opensim
-0.9.0.1-468-g235dd37\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 1680
   at OpenSim.Region.Framework.Scenes.ScenePresence.Teleport(Vector3 pos) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\Open
Sim\Region\Framework\Scenes\ScenePresence.cs:line 1660
   at OpenSim.Region.CoreModules.Framework.EntityTransfer.EntityTransferModule.TeleportAgentWithinRegion(ScenePresence s
p, Vector3 position, Vector3 lookAt, UInt32 teleportFlags) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\OpenSim\Region\Core
Modules\Framework\EntityTransfer\EntityTransferModule.cs:line 508
   at OpenSim.Region.CoreModules.Framework.EntityTransfer.EntityTransferModule.Teleport(ScenePresence sp, UInt64 regionH
andle, Vector3 position, Vector3 lookAt, UInt32 teleportFlags) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\OpenSim\Region\
CoreModules\Framework\EntityTransfer\EntityTransferModule.cs:line 408
22:19:09 - [WATCHDOG]: Timeout detected for thread "bulletunmanaged (ElvenSong)". ThreadState=Background, WaitSleepJoin.
 Last tick was 7266ms ago.

(0033214)
BillBlight (developer)
2018-10-20 20:45

Is this master code or release?
(0033216)
SnootsDwagon (reporter)
2018-10-20 20:48
edited on: 2018-10-20 20:49

Dunno Watcher. What's the difference? (Scuse my ignorance on this. Still learning.)

The above log indicates:
opensim-0.9.0.1-468-g235dd37

(0033217)
BillBlight (developer)
2018-10-20 20:50
edited on: 2018-10-20 20:54

There have been quite a few updates in the master code since the release of .9x some of them to the teleport code ..

^^Make sure at least you have the very latest from osgrid to confirm ...^^

Ok that does look like the current osgrid release, we were both posting at the same time ..

(0033218)
SnootsDwagon (reporter)
2018-10-20 20:53
edited on: 2018-10-20 20:55

This was the very latest code available to me... the same version used at OSgrid central. If this system follows standard protocol, the above identifier should indicate exactly which version it is, and the log file should indicate what happened when the teleport was attempted and failed.

Pardon me for tonight, bedtime here. : ) Will check back in tomorrow.

(0033219)
BillBlight (developer)
2018-10-20 20:56

Most likely this is the culprit

22:19:09 - [WATCHDOG]: Timeout detected for thread "bulletunmanaged (ElvenSong)". ThreadState=Background, WaitSleepJoin.
 Last tick was 7266ms ago.

the physics engine hung and took the rest of the sim with it ..

Willing to bet if you just let it set for a few minutes it will come back ..

When a thread hangs like that it can cause the whole simulator to hang ..

(not saying it does not need to be fixed just pointing out what may be the actual cause and not actually the TP)
(0033220)
BillBlight (developer)
2018-10-20 20:57

and actually that whole series of events starts with a bulletsim physics error ..

, 3518>@ElvenSong: Object reference not set to an instance of an object. at OpenSim.Region.PhysicsModule.BulletS.BSAPI
Unman.SetLinearVelocity(BulletBody obj, Vector3 vel) in k:\OSGRID\opensim-0.9.0.1-468-g235dd37\OpenSim\Region\PhysicsMod
ules\BulletS\BSAPIUnman.cs:line 1219
(0033221)
SnootsDwagon (reporter)
2018-10-20 21:00

Good starting point anyway. Next time it happens I'll let the server sit for 10 minutes or so and see if the problem clears up. Would be good if it does-- at least that would mean the region hasn't totally crashed. Will let you know when it happens. Can't predict when the next instance will occur, but very likely to happen again within at least 48 to 72 hours or so. Thanks for the heads up.
(0033222)
BillBlight (developer)
2018-10-20 21:03

hate to sound like a used car salesman, but willing to bet if you switched to ubODE it does not happen at all ..

Bullet is really not being actively maintained anymore.
(0033223)
SnootsDwagon (reporter)
2018-10-21 00:04

Can't disagree there Watcher. That was the first thought that hit my mind. I hate losing all the Bullet-scripted items, but at the same time they don't do much good if my region crashes at random teleports. May have to switch to Ubode this week.
(0033225)
UbitUmarov (administrator)
2018-10-21 04:25

Yes bullet made a mess :(

I made a "guess" code change on master...

http://opensimulator.org/viewgit/?a=commit&p=opensim&h=09865557650b4d1b36d8ebf292191d0feb1445fa [^]

set UseSeparatePhysicsThread = false
this should reduce threading issues a bit within bullet
Heartbeat thread has not much else to do and it should slow down with physics overload.
the fact things stop showing up on timing stats does not mean that are not eating cpu and taking time.
(0033226)
SnootsDwagon (reporter)
2018-10-21 07:01
edited on: 2018-10-21 07:04

"set UseSeparatePhysicsThread = false"

Do we put this in the opensim.ini file? If so, where?


[edit] Ah, I found it. Changed and testing. Thanks!

(0033227)
BillBlight (developer)
2018-10-21 09:35

SnootsDwagoon, that may only fix the issue with the new code Ubit pushed to Master which means it will need to be downloaded and compiled. (or wait for osGrid to do it)
(0033228)
SnootsDwagon (reporter)
2018-10-21 12:07

Got it. So what is best at this time.. switch to Ubode?
(0033229)
BillBlight (developer)
2018-10-21 12:18

That, or take it as a learning opportunity to learn to compile it from source ...
(0033230)
aiaustin (developer)
2018-10-21 12:27

@SnootsDwagon ... if you don’t yet have the details of how to get edit mode cut and paste for the Windows Command console... its worth looking at changing the defaults for that to tick quick edit and if you have not done so make the buffer length as big as you can (999)

See, for example,
https://www.tekrevue.com/tip/boost-productivity-quickedit-mode-windows-command-prompt/ [^]
(0033231)
SnootsDwagon (reporter)
2018-10-21 14:57
edited on: 2018-10-21 15:03

Watcher, I would learn to compile from source but I don't have available a double-barrel shotgun so I can shoot myself in both feet at the same time. ; )

(I use virtual worlds as a creator, scripter, merchant and group founder, not as a computer tech. No desire to add "messes with source code" to the list. I don't use Blender either unless I just *have* to.)

I'm afraid you're correct on Ubit's change. I applied it and tested. Discovered two things: 1) the problem still exists and 2) How to replicate this problem regularly.

To replicate this problem, set up 3 or 4 osTeleportAgent() objects that TP between one another on touch event-- and use them repeatedly, one right after another. Eventually this bug will trigger. (At least, did so from my experiments.) This is no longer a non-replicable bug. However on a standalone system where there are no network issues and the server runs a zillion times faster, this bug may not show up. However, I consider that "unrealistic testing"... as it does not test the software in real-life, cross-network use. Testing on a stand-alone system is like testing the mileage in a car in a closed room sitting on bearing rollers. The resulting mileage will not be accurate. (They used to do this. That is now against Federal law.) Testing in "laboratory" conditions is not usually indicative of real life "stress tests" where the network and other avatars are present. Just an observation. To test this properly, gonna have to get out of the house and "out into the real world". ; )

Seems switching to Ubode is the current answer.

Aiaustin-- thanks for that nifty tip!

(0033232)
BillBlight (developer)
2018-10-21 15:07
edited on: 2018-10-21 15:47

/me hands SnootsDwagoon a shotgun ... :P~~~~~~~

No but seriously , yeah not for everyone, but knowledge , even that which you don't plan on using often is good to learn ..

The day we wake up and and decide not to learn is the day we shouldn't wake up ..

That's my motto anyway ..


Yes, I tested on my grid, over multiple servers and could not replicate it, but then again that was before we knew it was a bulletsim error, and I use ubODE exclusively ....

(0033233)
UbitUmarov (administrator)
2018-10-21 15:55

the setting UseSeparatePhysicsThread = false is a suggestion for all versions.
do not see much gain on adding still another thread for already busy cpu cores, but guess minimal impact on this issue, bc without it the actions for local tps still happen on diferent threads.

The code change on master, was i said was a guess, did remove some potencial issues, But Bullet module is not my area.

did you test the code change or just the setting change?
(0033235)
SnootsDwagon (reporter)
2018-10-21 20:33
edited on: 2018-10-21 22:02

Watcher: I haven't stopped learning. I'm just getting wiser about what I choose to spend my time learning. There are only so many hours in a day and I have other demands on those hours. ; )

Ubit... I made a setting change to opensim.ini... but what "code change" are you speaking of?

I will mention again: I am a user, not a dev. I don't assemble code. I report bugs... and leave the bug fixing to others. (Although if reporting a bug is this time consuming and difficult, it is understandable users may be hesitant to file bug reports.)

As a summary of what has gone before:

I initially reported a bug with gth causing a region crash.

I was told that was a viewer function. I responded that viewer function is causing the region to crash-- thus making it an Opensim issue as well.

I was told by two people the issue could not be replicated.

I replied this had been reported as an intermittent bug-- which by definition means it can be very difficult to replicate and pin down.

I was asked to provide a chunk of log code, and told how to do so.

This same bug hit when osTeleportAgent() was executed. Fortunately this happened when two witnesses were present. It affected every user on the region-- which proved it was not a viewer-related issue. (Or if it was, it initiated a significant region freeze, which makes it an Opensim issue as well.)

As requested, I posted a considerable chunk of server log code, beginning with the teleport action and following the bug completely through its action.

I was then asked if I was using the "latest opensim" version.

I responded the exact Opensim version number was listed in every line of the log code-- and the log code itself displayed exactly what was going on throughout the entire freeze process.

It was then admitted that yes, evidently there is a bug and it's in the Bullet physics area.

We were again told that repeated attempts to replicate the bug had failed-- but those attempts had been made using the Ubode physics engine. It should be of no surprise then that trying to replicate an intermittent bug using a different physics engine is not going to reproduce the bug. Traditionally bug testing is best done at the REGION OF ORIGIN, not in a sealed test zone or regions using different environment settings.

At this time I am satisfied that this bug has been reported, has been verified and the cause identified, the log file is posted and bug tracking been accomplished. These things were done by a USER. (I feel it warranted to ask: by what criteria and protocol is a USER expected to have the knowledge and skill set to track down a major system bug?)

Since this bug has now been reported, discovered, identified and verified, the next step is for this major block-level bug to be fixed. My thoughts on that is that a *user* should not be expected to have the knowledge, nor to acquire the knowledge, to do so. That's what devs are for.

I believe the above summarizes this Mantis report. My personal solution to this-- as a user-- is to switch to Ubode because evidently Bullet physics has a serious bug that can cause my VAR to freeze on a regular basis. What Opensim decides to do about this-- that's someone else's area. I build custom guitars and amplifiers. Fixing Opensim computer code: not my job. If you need a killer guitar system, give me a hollar. ;D

(0033238)
SnootsDwagon (reporter)
2018-10-21 22:28

As a (hopefully) final post by me on this Mantis:

I switched ElvenSong to Ubode this evening. Ran intensive tests and did not replicate the problem under Ubode. So for me personally the problem is no longer of concern.

However for those running Bullet sims, this issue still presents for anyone using gth or the osTeleportAgent() function.
(0033240)
BillBlight (developer)
2018-10-22 08:25
edited on: 2018-10-22 08:27

Without the initial logs to point to bullet, it was an assumption to test the actual functions. And even on sims with bullet , under as much less load, the problem did not occur.

So until the log was shown that clearly showed the bullet error, there was not even a thought to bullet being the cause, and therefore only tested the functions themselves.

That bullet error will affect ALL functions on the sim not just those two, when it occurs , just seems rapid teleports trigger it earlier.

Had the report been ,"Bulletsim crashing on teleports, please see logs" a different approach would have been taken ..

You don't immediately look under the hood when someone tells you all that is wrong with the car is a flat tire.

(0033241)
SnootsDwagon (reporter)
2018-10-22 09:08
edited on: 2018-10-22 11:35

Watcher I understand what you're saying. But to further your automobile analogy, we have the customer saying "There's a noise in my engine" and the mechanic replying, "I can't replicate that noise in my engine." Literally.

Then the customer is then told to disassemble his engine and see if the rings are at the right tolerances. Then maybe the mechanic will step in if the customer finds out exactly where the problem is located.

I didn't say "the car has a flat tire" when the problem is observably elsewhere. I described the *effect* of the bug precisely and indicated it was an intermittent bug. That in itself should have offered enough information to begin standard established-method debugging procedure.

Again, AS A USER I should not be expected to understand the source of the bug.
A user can HELP hunt bugs (if they have the time and ability), but that help will need precise guidance. "We cannot replicate that bug" is not precise guidance in the debugging process.

Note that in this case, even AFTER I posted the log file, questions were asked such as "were you using the latest version of Opensim?"... when the precise version of Opensim was clearly listed on every line of that log file. That told me clearly that someone wasn't taking this seriously enough to properly examine the log file. Watcher later did so... and located the problem.

When one is trying to replicate a bug, we first of all make sure we are doing so in the same environment in which the user is functioning. Using a different software version, different settings, on a "local mode" system without all the glitches and ticks of the Net and in this case... not ascertaining in the first place what version of Opensim and Physics engine was in use, will most likely result in failure to replicate the bug. Declaring "I can't replicate this bug" then comes as no surprise... and is of no assistance in locating that very real bug.

Which is why I mentioned from the beginning that trying to replicate this bug by the methods being used was a futile effort. The proper procedure would have been to *come to ElvenSong*... find out what Opensim version and physics engine I am using (and even scripting engine if there are different versions of that)... and attempt to replicate the problem at ground zero. After doing exactly that myself (again, as a user), I managed to replicate the error pretty quickly... with witnesses, without even trying to do so. Once it was proved the error did indeed exist (which really, should have been taken seriously the moment I reported the bug)... then the follow-up steps could be taken to find out WHERE the problem originates.

When a customer calls a company and says, 'I can't get this software to print to my printer'... one doesn't answer "We can't replicate your problem on our printers." Which is why I am bringing this to attention. There are correct methods for debugging and incorrect ones. To lay the cards on the table, "Can't replicate this error" is not proper debugging procedure. It is the polar opposite of proper debugging procedure.

My goal here is to help improve the process in handling future bug reports so that bugs are properly located, identified and corrected. I hope my intent comes across as helpful rather than critical.

(0033244)
aiaustin (developer)
2018-10-23 01:42
edited on: 2018-10-23 01:43

I understand @SnootsDwagon's frustration with trying to file a bug report that includes quite a bit of detail but may not be precisely pinned down or replicable in all situations. Such reports are very useful and we should encourage rather than discourage them. They eventually can corelate if people see similar issues so we can narrow down the platform, environment or situations in which they may and may not occur.

To reassure @SnootsDwagon (who is a VERY experienced creator and user in Second Life and in various OpenSim grids) we have a LOT of this type of issue in OpenSim and its best to treat such reports as helpful and indicative of potential problems even if we have not yet managed to find the cause(s). I file such reports myself to help track things down and often look up related search terms when trying to narrow down such issues.

Thanks for your reports @SnootsDwagon - keep them coming.

(0033249)
UbitUmarov (administrator)
2018-10-23 07:25
edited on: 2018-10-23 08:26

"At random, unpredictable times" is a bug fixes killer. Even when some people can reproduce it and Devs can't.

In this cases the most that can be done is, as I did, "blind educated guesses changes".

As AiAustin said though that does not make the report useless, a fix response may just take ages. Meanwhile we all get aware and can report more information..

Finding if an issue is a viewer issue, or region, etc, is not also that easy in some cases.

(0033256)
SnootsDwagon (reporter)
2018-10-23 13:29
edited on: 2018-10-23 13:50

Aiaustin thank you for your kind words. It is my wish to help improve the Opensim system. Improvement of the system benefits everyone.

When I speak here of established debug procedures, it is simply so that bugs can be found, identified and fixed in the shortest possible time. Decades of procedure have created a method for debugging code, a step-by-step process that has proved over time to work. I've used that method all my life to great benefit. That's why I'm eager to see such procedures implemented in the Opensim project. Happy to help in any way I can. I'm not an Opensim dev or tech but am an "experienced user" and will happily help track down bugs with great zeal. ;D

Ubit you are absolutely correct when you speak of difficulty in reproducing some types of bugs. Sometimes it can be nearly impossible and as you state, "Blind educated guesses" often win the day in such instances. We try something just to see if that's it, it works, HURRAH! :D

(0033263)
SnootsDwagon (reporter)
2018-10-25 19:42

Additional note: there seems to be physics freezes both in Bullet and in Ubode. A friend of mine and I both experienced a physics freeze under Ubode tonight. She crashed. For me everything worked, but my avatar stopped animating and didn't restart until 2-3 minutes later. I could still travel and teleport etc, but the avatar was frozen solid.

- Issue History
Date Modified Username Field Change
2018-10-18 19:39 SnootsDwagon New Issue
2018-10-18 19:41 BillBlight Note Added: 0033178
2018-10-18 19:47 BillBlight Note Edited: 0033178 View Revisions
2018-10-18 20:35 SnootsDwagon Note Added: 0033179
2018-10-19 08:50 Luisillo_Contepomi Note Added: 0033182
2018-10-19 08:57 Luisillo_Contepomi Note Edited: 0033182 View Revisions
2018-10-19 09:32 SnootsDwagon Note Added: 0033183
2018-10-19 09:39 SnootsDwagon Note Edited: 0033183 View Revisions
2018-10-19 09:48 BillBlight Note Added: 0033184
2018-10-19 10:14 SnootsDwagon Note Added: 0033185
2018-10-19 10:18 BillBlight Note Added: 0033186
2018-10-19 10:19 SnootsDwagon Note Edited: 0033185 View Revisions
2018-10-19 10:23 BillBlight Note Edited: 0033186 View Revisions
2018-10-19 10:25 BillBlight Note Added: 0033187
2018-10-19 10:26 SnootsDwagon Note Added: 0033188
2018-10-19 10:32 SnootsDwagon Note Added: 0033189
2018-10-19 10:33 SnootsDwagon Note Added: 0033190
2018-10-19 10:38 BillBlight Note Added: 0033191
2018-10-19 10:41 SnootsDwagon Note Added: 0033192
2018-10-19 10:44 SnootsDwagon Note Added: 0033193
2018-10-19 10:47 SnootsDwagon Note Edited: 0033193 View Revisions
2018-10-19 10:49 SnootsDwagon Note Edited: 0033193 View Revisions
2018-10-19 11:32 SnootsDwagon Note Edited: 0033193 View Revisions
2018-10-19 12:17 SnootsDwagon Note Added: 0033194
2018-10-19 12:19 SnootsDwagon Note Deleted: 0033193
2018-10-19 12:44 BillBlight Note Added: 0033195
2018-10-20 19:49 SnootsDwagon Note Added: 0033210
2018-10-20 19:51 Koni Lanzius Note Added: 0033211
2018-10-20 20:15 SnootsDwagon Note Edited: 0033210 View Revisions
2018-10-20 20:23 John Sunekova Note Added: 0033212
2018-10-20 20:30 SnootsDwagon Note Added: 0033213
2018-10-20 20:36 SnootsDwagon Summary gth causes "teleport failure" and crash => osTeleportAgent() and gth causes "teleport failure" and crash
2018-10-20 20:36 SnootsDwagon Description Updated View Revisions
2018-10-20 20:36 SnootsDwagon Additional Information Updated View Revisions
2018-10-20 20:45 BillBlight Note Added: 0033214
2018-10-20 20:45 SnootsDwagon Note Edited: 0033213 View Revisions
2018-10-20 20:45 SnootsDwagon Note Edited: 0033194 View Revisions
2018-10-20 20:47 SnootsDwagon Note Edited: 0033213 View Revisions
2018-10-20 20:48 SnootsDwagon Note Added: 0033216
2018-10-20 20:49 SnootsDwagon Note Edited: 0033216 View Revisions
2018-10-20 20:50 BillBlight Note Added: 0033217
2018-10-20 20:53 SnootsDwagon Note Added: 0033218
2018-10-20 20:54 SnootsDwagon Note Edited: 0033218 View Revisions
2018-10-20 20:54 BillBlight Note Edited: 0033217 View Revisions
2018-10-20 20:55 SnootsDwagon Note Edited: 0033218 View Revisions
2018-10-20 20:55 SnootsDwagon Note Edited: 0033218 View Revisions
2018-10-20 20:56 BillBlight Note Added: 0033219
2018-10-20 20:57 BillBlight Note Added: 0033220
2018-10-20 21:00 SnootsDwagon Note Added: 0033221
2018-10-20 21:03 BillBlight Note Added: 0033222
2018-10-21 00:04 SnootsDwagon Note Added: 0033223
2018-10-21 04:25 UbitUmarov Note Added: 0033225
2018-10-21 07:01 SnootsDwagon Note Added: 0033226
2018-10-21 07:04 SnootsDwagon Note Edited: 0033226 View Revisions
2018-10-21 09:35 BillBlight Note Added: 0033227
2018-10-21 12:07 SnootsDwagon Note Added: 0033228
2018-10-21 12:18 BillBlight Note Added: 0033229
2018-10-21 12:27 aiaustin Note Added: 0033230
2018-10-21 14:57 SnootsDwagon Note Added: 0033231
2018-10-21 14:57 SnootsDwagon Note Edited: 0033231 View Revisions
2018-10-21 15:01 SnootsDwagon Note Edited: 0033231 View Revisions
2018-10-21 15:03 SnootsDwagon Note Edited: 0033231 View Revisions
2018-10-21 15:07 BillBlight Note Added: 0033232
2018-10-21 15:47 BillBlight Note Edited: 0033232 View Revisions
2018-10-21 15:55 UbitUmarov Note Added: 0033233
2018-10-21 20:33 SnootsDwagon Note Added: 0033235
2018-10-21 21:20 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:22 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:24 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:26 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:48 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:49 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:49 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:51 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 21:58 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 22:00 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 22:02 SnootsDwagon Note Edited: 0033235 View Revisions
2018-10-21 22:28 SnootsDwagon Note Added: 0033238
2018-10-22 08:25 BillBlight Note Added: 0033240
2018-10-22 08:26 BillBlight Note Edited: 0033240 View Revisions
2018-10-22 08:27 BillBlight Note Edited: 0033240 View Revisions
2018-10-22 09:08 SnootsDwagon Note Added: 0033241
2018-10-22 09:09 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:18 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:24 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:25 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:28 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:29 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:30 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:31 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:32 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:33 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:45 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:47 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:49 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:51 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:52 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:53 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:54 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:57 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 09:59 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 10:01 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 10:03 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 10:40 Luisillo_Contepomi Note Added: 0033242
2018-10-22 10:41 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 11:06 Luisillo_Contepomi Note Deleted: 0033242
2018-10-22 11:21 SnootsDwagon Note Edited: 0033185 View Revisions
2018-10-22 11:23 SnootsDwagon Note Edited: 0033189 View Revisions
2018-10-22 11:27 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 11:31 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 11:35 SnootsDwagon Note Edited: 0033241 View Revisions
2018-10-22 11:48 SnootsDwagon File Added: Teleport Failed. Internal Error..png
2018-10-22 11:49 SnootsDwagon File Deleted: Teleport Failed. Internal Error..png
2018-10-22 11:49 SnootsDwagon File Added: Teleport Failed. Internal Error..png
2018-10-23 01:42 aiaustin Note Added: 0033244
2018-10-23 01:43 aiaustin Note Edited: 0033244 View Revisions
2018-10-23 07:25 UbitUmarov Note Added: 0033249
2018-10-23 08:25 aiaustin Note Edited: 0033249 View Revisions
2018-10-23 08:25 aiaustin Note Edited: 0033249 View Revisions
2018-10-23 08:26 aiaustin Note Edited: 0033249 View Revisions
2018-10-23 13:29 SnootsDwagon Note Added: 0033256
2018-10-23 13:30 SnootsDwagon Note Edited: 0033256 View Revisions
2018-10-23 13:31 SnootsDwagon Note Edited: 0033256 View Revisions
2018-10-23 13:32 SnootsDwagon Note Edited: 0033256 View Revisions
2018-10-23 13:50 SnootsDwagon Note Edited: 0033256 View Revisions
2018-10-25 19:42 SnootsDwagon Note Added: 0033263


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker