Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008513opensim[REGION] OpenSim Corepublic2019-04-05 08:222019-11-01 03:03
Reportermewtwo0641 
Assigned Tomewtwo0641 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionmaster (dev code) 
Summary0008513: Teleport refused because failed to verify user presence
DescriptionTeleport fails between two regions with error in console and viewer:

2019-04-05 10:13:53,091 DEBUG [ENTITY TRANSFER MODULE]: Teleport of Test User from Test Region 1 to Test Region 2 was refused because Failed to verify user presence in the grid for Test User, access denied to region Test Region 2.

The regions are setup to where they are not immediately next to each other like this: [Test Region 1] [Void] [Test Region 2]

Teleport works one time to either region and then every subsequent teleport attempt thereafter fails with the above message. The only way I have found to get around this is to relog and then teleport to the desired region; but after that it is back to square one with the error messages, relog to teleport, repeat.

Strangely this does not happen with two completely blank regions; I only started noticing this when I started building and putting stuff out on the second region and attempted to teleport back to the first region and it failed. Blanking the regions out lets me teleport back and forth fine again but as soon as I start putting stuff out again teleports start to fail in this fashion.

Currently I see this on OSGrid with my two region test setup. I have not yet tested this on a local grid.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Viewer
Attached Files

- Relationships

-  Notes
(0035029)
BillBlight (developer)
2019-04-05 08:36

This may be a specific osGRID issue due to the regular cleaning of the presence table.
(0035030)
mewtwo0641 (reporter)
2019-04-05 09:30

Possibly... But does it get cleaned out on each relog? Because I can make this happen consistently: Login > Teleport > Try teleport back; fails. Relog, can teleport once, fails every time after; repeat.

I will test and see if it's an issue on local grid and post the results here later on when I get a chance.
(0035032)
mewtwo0641 (reporter)
2019-04-05 19:59
edited on: 2019-04-05 20:41

After some testing on local grid (Not OSGrid) I can also trigger this issue. I ran git bisect and found a bad commit in which it started happening but I don't think it found the correct commit because compiling the commit before that still exhibited the issue. So I think the issue is not quite as consistent as I first thought it is. Will need to run bisect again and see if I can find a point where the bisect result makes more sense.

(0035035)
mewtwo0641 (reporter)
2019-04-05 23:09
edited on: 2019-04-05 23:33

5 git bisect sessions later... I think I have come up with a commit that makes sense now at commit df14ed7d312e2f38e21912447835d9f078b97a95

I did some extensive testing on the commit just before that one and can't get the issue to trigger. So I feel more confident that the issue starts appearing at df14ed7d312e2f38e21912447835d9f078b97a95


Git Bisect Results:

$ git bisect bad
df14ed7d312e2f38e21912447835d9f078b97a95 is the first bad commit
commit df14ed7d312e2f38e21912447835d9f078b97a95
Author: UbitUmarov <ajlduarte@sapo.pt>
Date: Mon Jan 14 18:39:16 2019 +0000

    more on TP

:040000 040000 487d8bfaa32227c005e9862f77e98f5c3491c7b7 38063a13dcbdaae3bf790a9ae167c2c56c614ab9 M OpenSim
:040000 040000 9caa783069181cfc0cdecac35ed085f548b14e09 0ae596f7081ba2d5aea0a1a4609e4d6c0fc9565b M bin

(0035037)
BillBlight (developer)
2019-04-06 02:13

This is another one of those odd ones, as I'm running my whole grid on the new code, and nobody is getting this error ...

I'm sure it is a combination of things causing it, just don't know what the secret sauce is ..
(0035038)
mewtwo0641 (reporter)
2019-04-06 10:12

I have noticed that if NPCs are involved, as in, the creation of them and removal of them before TPing back and forth, it seems to make this trigger more easily.
(0035039)
BillBlight (developer)
2019-04-06 10:28

@mewtwo0641 Try the latest master Ubit has been working on that I think ...
(0035040)
mewtwo0641 (reporter)
2019-04-06 18:18

I just gave master a try but the issue still persists
(0035064)
BillBlight (developer)
2019-04-08 04:43

The only way I have found to trigger this is doing "Suicidal" TP's , if you let both the receiving and sending regions settle , it does not seem to happen.
(0035069)
mewtwo0641 (reporter)
2019-04-08 19:07

I did some more testing on this but this time with a new database and still see the issue. A new thing that I have noticed is that any regions that decide that the user is no longer online will be invisible to the user even if they are directly adjacent to the region the user is in ([Region][Region] As opposed to my original setup of [Region][Void][Region]).

Some regions within the same OpenSim instance will still accept TPs and some won't and will be invisible to the user. The regions that do and do not appear to be at random. Whenever a user TPs to a region that is still accepting TPs from that user there's a flood of messages in the console listing off the regions that aren't accepting TPs that look like this:

[ENTITY TRANSFER MODULE]: Region (Region Name) did not accept (User Name) (User UUID): Failed to verify user presence in the grid for (User Name), access denied to region (Region Name)

This scenario is more obvious when there are more than a couple regions on the OpenSim instance (The one I tested this time had about 10 regions).
(0035072)
mewtwo0641 (reporter)
2019-04-09 04:04

This seems improved now as of master (commit f29fdb6bdae51e50f749e2144a3e92fb3171f436) but will keep an eye on it before confirming fixed since it's a random occurrence.
(0035812)
mewtwo0641 (reporter)
2019-11-01 03:03

Haven't seen this issue for a while. Seems fixed by master.

- Issue History
Date Modified Username Field Change
2019-04-05 08:22 mewtwo0641 New Issue
2019-04-05 08:36 BillBlight Note Added: 0035029
2019-04-05 09:30 mewtwo0641 Note Added: 0035030
2019-04-05 19:59 mewtwo0641 Note Added: 0035032
2019-04-05 20:41 mewtwo0641 Note Edited: 0035032 View Revisions
2019-04-05 21:07 mewtwo0641 Note Added: 0035034
2019-04-05 21:09 mewtwo0641 Note Edited: 0035034 View Revisions
2019-04-05 21:35 mewtwo0641 Note Deleted: 0035034
2019-04-05 23:09 mewtwo0641 Note Added: 0035035
2019-04-05 23:33 mewtwo0641 Note Edited: 0035035 View Revisions
2019-04-06 02:13 BillBlight Note Added: 0035037
2019-04-06 10:12 mewtwo0641 Note Added: 0035038
2019-04-06 10:28 BillBlight Note Added: 0035039
2019-04-06 18:18 mewtwo0641 Note Added: 0035040
2019-04-08 04:43 BillBlight Note Added: 0035064
2019-04-08 19:07 mewtwo0641 Note Added: 0035069
2019-04-09 03:32 aiaustin Relationship added related to 0008515
2019-04-09 03:32 aiaustin Relationship deleted related to 0008515
2019-04-09 04:04 mewtwo0641 Note Added: 0035072
2019-11-01 03:03 mewtwo0641 Note Added: 0035812
2019-11-01 03:03 mewtwo0641 Status new => resolved
2019-11-01 03:03 mewtwo0641 Fixed in Version => master (dev code)
2019-11-01 03:03 mewtwo0641 Resolution open => fixed
2019-11-01 03:03 mewtwo0641 Assigned To => mewtwo0641


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker