Permissions problem within the engine?

[manu3d]

I just attempted to work out an issue @Immortius and I discussed long time ago, but according to the debugger I'm running into module permission problems. Which is peculiar given that modules shouldn't be involved at all and this is all within-the-engine work.

The relevant changes to one of my local branches are visible in this commit. The key feature of this commit is that I copied and only minimally modified the content of LwjglRenderingProcess.createFBO() to FBO.Builder.build(), a new static class within the rendering/opengl/FBO class. I had just started testing the builder and in this commit it is used only once, at the beginning of LwjglRenderingProcess.recreateDynamicFBOs();

With this commit the game doesn't start (black screen) nor seems to provide any meaningful errors. Running through the debugger it appears that the FBO.Builder class is hitting permission problems of some kind.

What am I doing wrong?

 

[manu3d]

Meanwhile, it turns out there is a single offensive line in FBO.Builder.build():

LwjglRenderingProcess.getInstance().deleteFBO(title);

Removing the line seems to solve the problem. But whyyyyyyyy??? :thunk: :thunk: :thunk: (head banging against nearest reinforced concrete wall)

 

[Cervator]

Was that before or after @msteiger offered some alternative code? I see a comment on your commit. His version moves the order of things around a bit, looks like.

The permissions can get a little squirrely if modules trigger early stuff in the engine (early initialization?), where whitelisting / privileged blocks previously were in place to allow it. I don't know if that's what at play here, I've just noted a few issues related to interesting situations in the past.

 

[manu3d]

@msteiger's code helped, in the sense that it gave me ideas on how to work around the problem. I eventually solved the issue by passing the instance of the LwjglRenderingProcess to the builder, as a constructor argument. Somehow that's not a problem. Having the aformentioned line in the builder code is a problem.

Early initialization might indeed be the issue. While debugging I noticed that there are parts of the rendering code that are executed just before the main menu appears, well before any game is loaded. Having found a workaround and having this been the only time I stumbled upon this issue I won't look any deeper into it. I will however write an issue about it and leave the branch available on my repository, just in case somebody will want to investigate.

 

[Immortius]

Could do with a stacktrace, but:

When a permission check is done, the sandboxing code will check if a module is involved in the stack trace at all. If it is, then the module is checked for the permission. If it is intended that the permission check be run at the engine's access level the code triggering the permission check needs to be wrapped in an AccessController.doPriviledged() block.

Where things can act up is where there is some once-off code that will run when code is first used that requires permission. If the engine triggers it before the module then it will work fine, but if a module triggers it first it will fail without the doPriviledged block.

It may also be possible to have issues if permission checks are triggered before the module security manager is installed.

 

[manu3d]

Thank you @Immortius for the reply.

When the problem occurs Terasology hangs, so there is no stacktrace output in the log - Terasology isn't crashed yet. The information I provided were obtained by running Terasology through the debugger and inserting break points to find out where it hangs. I wouldn't have known there's a module security involved otherwise. Perhaps there's a way to obtain the stack trace through the debugger?

In general I'd find it hard to believe that there is any module involved. The problem arises from engine/rendering/opengl code and in particular a call to LwjglRenderingProcess.getInstance().deleteFBO(). The only thing (not so) special about the deleteFBO() method is that it has a few lines of opengl code. Perhaps your third suggestion is relevant then? A timing issue?

The reason I suggest it'd be worth for you looking into it though is that Terasology hangs. Had it crashed at least we'd know so much more. Hanging is probably the worst possible outcome and I'd imagine that's not what the module security should ever do?

 

[Immortius]

Hmm, on further inspection you have an infinite loop in your code.

LwjglRenderingProcess::getInstance()->LwjglRenderingProcess::new->initialise->recreateDynamicFBOs->builder.build()->LwjglRenderingProcess::getInstance()

instance isn't set until after the constructor is complete, so when the builder calls getInstance() during the constructor call another instance is created, and this continues. One of the reasons why singletons are evil.

The module security is irrelevant, it just happens that there are permission checks during this process.

 

[manu3d]

Shut! Sorry about that. I was completely misled by the debugger then. Sorry to have bothered you about something that turned out so simple. Next time something hangs unexpectedly I'll think about this episode.

Regarding singletons, I didn't know they were evil, but I have been questioning the necessity of having LwjglRenderingProcess as a singleton. I might eventually propose a version in which it is not.