Am 06.06.2014 10:02, schrieb Sönke Ludwig:
Am 06.06.2014 09:31, schrieb Darius Clark:
On Fri, 06 Jun 2014 08:34:54 +0200, Sönke Ludwig wrote:
Am 06.06.2014 02:23, schrieb Darius Clark:
Hi,
I am having a issue currently with getting segfaults when attempting
to access sessions.The current code is
class AuthenicateService{ private SessionVar!(AuthSess, "AuthSess") authSess; @path("/login") @method(HTTPMethod.GET) void GetLogin(){ auto auth = authSess; if(auth.isValid) //segfault redirect("/dashboard"); render!("login.index.jade", auth); } }
I do not know why it does this. In the example, there is no segfault
and it points to the line thats currently commented. The other way
would just adding the param for the sessions directly.Do you have a
HTTPServerSettings.sessionStore
set? The strange thing
is though that there should be an assertion error message in that case,
so if this is not the reason, can you try to get full a stack trace by
running it inside GDB?Or is
AuthSess
a class type and maybe still initialized tonull
?When I ran gdb, I got
Program received signal SIGSEGV, Segmentation fault. 0x0000000000728b00 in services.authenicate.AuthenicateService.GetLogin() ( this=0x7ffff7edcb80, req=0x7ffff7e8c020) at source/services/authenicate.d:22 22 if(auth.isValid)
I wouldnt see why the AuthSess class would still be initialized to
null. Any suggestions what I could do to fix it maybe?Do you have a place where it is explicitly initialized? It's hard to
tell from that snippet what exactly goes on. You'd basically have to
make sure it is initialized for every request, because you never know if
that request already has an associated session. But this just gave me
the idea to extendSessionVar
with an optional initializer delegate in
addition to a constant initializer value. Then the following would
always guarantee a validAuthSess
instance:SessionVar!(AuthSess, "AuthSess") authSess = { return new AuthSess; };
On a second thought, it's probably better to generally disallow class
,
as well as other mutable reference types. This kind of class
approach
works fine with the MemorySessionStore
, but will fail miserably when
for example storing the session data in a Redis database or similar. So
I think I'll add a check with the suggestion to use a struct
instead.
And for safety reasons, it would also be better to have the getter of SessionVar
always return a const
value, so that no hidden no-ops are
possible (e.g. sessionvar.someStructField = 42;
would only set 42 on a
temporary, but not in the session store).