|
Home > Archive > Apache Mod-Python > May 2005 > FileSession segfaulting (Was: Re: _apache.emergency_unlock function?)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
FileSession segfaulting (Was: Re: _apache.emergency_unlock function?)
|
|
| dharana 2005-05-22, 5:45 pm |
| More information about the segfault. It always happens after a certain ammount
of time. I believe it maybe this:
- session starts correctly
- I navigate throught many pages
- session timeouts
- segfault
It's just a supposition, I will try to confirm it.
I couldn't reproduce it with MemorySession because I use apache multithreaded
and when I tried to use DbmSession it throws an Exception in the do_save()
function. I'm using mod_python_20050518163650.tar.gz with the typo bug I
reported ( http://issues.apache.org/jira/browse/MODPYTHON-45 ) fixed.
I will report if I find out more info or I find an easy to reproduce testcase.
Jim Gallacher wrote:
> dharana wrote:
>
>
>
> segfault? Yikes.
>
>
>
> I'll see if I can reproduce the error as well.
>
> Jim
>
>
>
>
>
| |
| dharana 2005-05-22, 5:45 pm |
| This is driving me crazy. I'm finding it hard to make a simple testcase.
I use a custom handler and somewhere in the code I do this:
-- [snip] -------------------------------------------------------------
from mypackage.mysubpackage.mysubsubpackage import db
def run(req):
req.sess['foo'] = object
# req.sess['foo'] = db
req.sess.save()
return
# I redirect the user another path with util.redirect and then the segfault
# happens
----------------------------------------------------------------------
The moment I try to assign my own classes (ie: assigning db instead of object I
must manually delete the pysid cookie to stop the segfaults.
It seems as if mp corrupts or somehow leaves in an usable state the session
after trying to save my objects. I tried with different objects and it happens
with all of them. Does anyone knows how I can retrieve more info from the
segfault? I don't like segfaults  they don't tell why they don't like you.
dharana wrote:
> More information about the segfault. It always happens after a certain
> ammount of time. I believe it maybe this:
> - session starts correctly
> - I navigate throught many pages
> - session timeouts
> - segfault
>
>
> It's just a supposition, I will try to confirm it.
>
> I couldn't reproduce it with MemorySession because I use apache
> multithreaded and when I tried to use DbmSession it throws an Exception
> in the do_save() function. I'm using mod_python_20050518163650.tar.gz
> with the typo bug I reported (
> http://issues.apache.org/jira/browse/MODPYTHON-45 ) fixed.
>
> I will report if I find out more info or I find an easy to reproduce
> testcase.
>
| |
| dharana 2005-05-22, 5:45 pm |
| More info:
It just happens with some classes. Some work and some won't, and I don't yet
know why. Some info:
In my webapp when user logs in I save a User object (subclassing class
Storable). And then I redirect. Works ok, no problem.
Then, in another page I try to save a Website object (subclassing from both
Storable and Website). It segfaults.
Could it be something related to multiple inheritance? In my ignorance I thought
so, but then when I try to save a Dbobj class just for testing purposes it also
crashes. Dbobj inherits from object directly and has some methods defined as
classmethod.
My question is: how does mod_python knows where to look for a class while trying
to retrieve it? Imagine I start a session in namespace a and then in namespace b
I save a class instance which is only known to namespace b. What happens when
namespace a tries to save the session or when it tries to load it again? How
does it knows where to look for the class instance only known to namespace b?
Maybe the problem lies there?
Anyway I will save the object_id in the session instead of the class instance
and I will load the object from it.
I'm really sorry for the spam. My head starts spinning really fast when I see
segfaults.
dharana wrote:
> This is driving me crazy. I'm finding it hard to make a simple testcase.
>
> I use a custom handler and somewhere in the code I do this:
>
> -- [snip] -------------------------------------------------------------
> from mypackage.mysubpackage.mysubsubpackage import db
>
> def run(req):
> req.sess['foo'] = object
> # req.sess['foo'] = db
> req.sess.save()
> return
>
> # I redirect the user another path with util.redirect and then the segfault
> # happens
> ----------------------------------------------------------------------
>
>
> The moment I try to assign my own classes (ie: assigning db instead of
> object I must manually delete the pysid cookie to stop the segfaults.
>
> It seems as if mp corrupts or somehow leaves in an usable state the
> session after trying to save my objects. I tried with different objects
> and it happens with all of them. Does anyone knows how I can retrieve
> more info from the segfault? I don't like segfaults they don't tell
> why they don't like you.
>
> dharana wrote:
| |
| Jim Gallacher 2005-05-24, 5:52 pm |
| Hi dharana,
I've been away for a few days, but should have some time to mess around
with this today.
dharana wrote:
> More info:
>
> It just happens with some classes. Some work and some won't, and I don't
> yet know why.
Do you ever see segfaults if you only saving strings in your session,
rather than objects? I have the feeling that I've seen mention of
problems trying to pickle some objects. (Both DbmSession and FileSession
create a pickle to store the data). I'm not sure if this was in the docs
or on the mailing list. I'll dig around to see what I can find.
Do you see the same segfault if you use DbmSession? If not then that
would rule out a pickle problem.
> Some info:
> In my webapp when user logs in I save a User object (subclassing class
> Storable). And then I redirect. Works ok, no problem.
>
> Then, in another page I try to save a Website object (subclassing from
> both Storable and Website). It segfaults.
>
> Could it be something related to multiple inheritance? In my ignorance I
> thought so, but then when I try to save a Dbobj class just for testing
> purposes it also crashes. Dbobj inherits from object directly and has
> some methods defined as classmethod.
>
> My question is: how does mod_python knows where to look for a class
> while trying to retrieve it? Imagine I start a session in namespace a
> and then in namespace b I save a class instance which is only known to
> namespace b. What happens when namespace a tries to save the session or
> when it tries to load it again? How does it knows where to look for the
> class instance only known to namespace b?
Interesting question. I'll need to refresh myself on the pickling mechanism.
> Maybe the problem lies there?
>
> Anyway I will save the object_id in the session instead of the class
> instance and I will load the object from it.
>
>
> I'm really sorry for the spam. My head starts spinning really fast when
> I see segfaults.
Hey, this is not spam.  And segfaults make my head spin too.
Regards,
Jim
>
> dharana wrote:
>
>
>
>
| |
| dharana 2005-05-24, 5:52 pm |
| Hi Jim,
Objects of types int, str, unicode, etc don't cause a segfault. Currently I'm
storing just a string and an User object of mine. It segfaults when an
undetermined ammount of time passes (it may be around 30 mins). It happens even
if I'm continually browsing not just staring at the screen and it happens almost
always.
If I try to store a DynamicWebsite object it segfaults every time and at that
moment, no need to wait some minutes.
Background info:
class User(Storable):
# one single method which calls another custom function in another module of
mine plus the inherited methods
class DynamicWebsite(Website, Storable):
# a more complex object. The base class Website assigns req to self.req. This
child class modifies it in one of it's three methods. Perhaps has something to
do? It also import custom modules from some of it's functions.
class Storable(object):
# just an interface to load/save from a db
I will be a bit busy until saturday. I will try to make a testcase then, but
it's not trivial.
Perhaps it has to do with circular dependencies with the req object?
Please look at my comment here:
http://issues.apache.org/jira/browse/MODPYTHON-45
I can't see wether this has anything to do with the problem at hand but just in
case.
Jim Gallacher wrote:
> Hi dharana,
>
> I've been away for a few days, but should have some time to mess around
> with this today.
>
| |
| Nicolas Lehuen 2005-05-24, 5:52 pm |
| Hi dharana, I have a two parts answer :
1) One thing I'm really sure is that there is no way for the pickle
module to handle the request object correctly. Hence, if the session
code is trying to pickle an object which contains a reference to a
request object, I have no idea of how this can be done. This is
another possible explanation of the segfault. Maybe you could try to
pickle then reload an object with a reference to the request object,
like this :
import cPickle
def index(req):
d =3D { "request" : req }
test1 =3D cPickle.loads(cPickle.dumps(d))
return str(test1)
In any case, storing an object with a reference to the request in a
session is not a godd thing to do ; a request is a transient object,
which is not meant to live for more than the request's processing
time.
3) Another possible problem with loading pickled sessions is the case
where you are trying to load some user-defined class instances.
Due to the way pickling works, the class of an instance is saved by
name, and the unpickling code automagically reimports the module of
the class and rebuild the instance from there.
When the class is defined in a published module (and this is also true
for mod_python 3.1.4 and before), I can't see how the unpickling code
can possibly find the proper published module, since the standard
importing mechanism won't find the published module. This should raise
a nice Python exception, but maybe with cPickle or in certain
circumstances this causes a segmentation fault.
To rule out this problem I would try to define the object class in a
module that could be found on the PythonPath, rather than directly in
the published module.
3) Uh oh. If you're suspecting that this problem is related to
circular dependencies with the request object, then maybe this bug is
caused by the changes I've made to support the garbage collection of
the request object, since I had to implement some traversal code that
could fail for a reason or another.
Would it be possible for you to perform the same tests with the 3.1.4
version of mod_python.so ? We would make clear whether this is due to
something like that.
Tell us if your experimentations gives some results ; I'll have a look
at this but it is much too late for me now.
Regards,
Nicolas
2005/5/24, dharana <dharana@dharana.net>:
> Hi Jim,
>=20
> Objects of types int, str, unicode, etc don't cause a segfault. Currently=
I'm
> storing just a string and an User object of mine. It segfaults when an
> undetermined ammount of time passes (it may be around 30 mins). It happen=
s even
> if I'm continually browsing not just staring at the screen and it happens=
almost
> always.
>=20
> If I try to store a DynamicWebsite object it segfaults every time and at =
that
> moment, no need to wait some minutes.
>=20
> Background info:
>=20
> class User(Storable):
> # one single method which calls another custom function in another module=
of
> mine plus the inherited methods
>=20
> class DynamicWebsite(Website, Storable):
> # a more complex object. The base class Website assigns req to self.req. =
This
> child class modifies it in one of it's three methods. Perhaps has somethi=
ng to
> do? It also import custom modules from some of it's functions.
>=20
> class Storable(object):
> # just an interface to load/save from a db
>=20
> I will be a bit busy until saturday. I will try to make a testcase then, =
but
> it's not trivial.
>=20
> Perhaps it has to do with circular dependencies with the req object?
>=20
> Please look at my comment here:
>=20
> http://issues.apache.org/jira/browse/MODPYTHON-45
>=20
> I can't see wether this has anything to do with the problem at hand but j=
ust in
> case.
>=20
>=20
> Jim Gallacher wrote:
>=20
> --
> dharana
>=20
>
| |
| dharana 2005-05-25, 5:46 pm |
| RESULTS OF TESTS
TEST:
Trying to picle/unpickle the req object:
CODE:
from mod_python import Session, apache
def handler(req):
d = { "request" : req }
test1 = cPickle.loads(cPickle.dumps(d))
req.write(str(test1))
RESULT:
TypeError: can't pickle mp_request objects
COMMENT:
Expected, req is a transient object that shouldn't be pickled. Exception thrown
------------------------
TEST: Check to see if segfault is caused by storing req obj directly in req.sess
CODE:
from mod_python import Session, apache
def handler(req):
req.sess = Session.FileSession(req)
req.sess['req'] = req
req.sess.save()
req.content_type = 'text/html'
req.write('session_id: %s' % req.sess.id())
RESULT:
New session is created on each request. No segfault.
COMMENT:
I suppose mp catches the Exception and silently creates a new session. It's not
a good design idea to store the req object so the designer should be punished.
----------------------
TEST: Check to see if segfault is caused by custom classes ()
CODE:
from mod_python import Session, apache
from ozone.storage.db import dbobj
def handler(req):
req.sess = Session.FileSession(req)
try:
req.write('I have the db! (%s)' % req.sess['dbobj'])
except KeyError:
pass
req.sess['dbobj'] = dbobj
req.sess.save()
req.write('session_id: %s' % req.sess.id())
RESULT:
Nothing except session_id gets printed on the first time. Next time it correctly
loads the session and prints "I have the db" with the same session_id.
COMMENT:
Works as expected.
This are just sanity checks. I restarted apache after each test and I also
deleted the pysid cookie to get clear results. I will post the weird results I
got one minute later in my next email.
(I've also commented Nicholas email below)
Nicolas Lehuen wrote:
> Hi dharana, I have a two parts answer :
>
> 1) One thing I'm really sure is that there is no way for the pickle
> module to handle the request object correctly. Hence, if the session
> code is trying to pickle an object which contains a reference to a
> request object, I have no idea of how this can be done. This is
> another possible explanation of the segfault. Maybe you could try to
> pickle then reload an object with a reference to the request object,
> like this :
>
> import cPickle
> def index(req):
> d = { "request" : req }
> test1 = cPickle.loads(cPickle.dumps(d))
> return str(test1)
>
> In any case, storing an object with a reference to the request in a
> session is not a godd thing to do ; a request is a transient object,
> which is not meant to live for more than the request's processing
> time.
>
> 3) Another possible problem with loading pickled sessions is the case
> where you are trying to load some user-defined class instances.
>
> Due to the way pickling works, the class of an instance is saved by
> name, and the unpickling code automagically reimports the module of
> the class and rebuild the instance from there.
>
> When the class is defined in a published module (and this is also true
> for mod_python 3.1.4 and before), I can't see how the unpickling code
> can possibly find the proper published module, since the standard
> importing mechanism won't find the published module. This should raise
> a nice Python exception, but maybe with cPickle or in certain
> circumstances this causes a segmentation fault.
>
> To rule out this problem I would try to define the object class in a
> module that could be found on the PythonPath, rather than directly in
> the published module.
Althought in the code above the import calls are in the handler in the full
version mp manages to find custom classes even if they are not imported in the
handler code.
>
> 3) Uh oh. If you're suspecting that this problem is related to
> circular dependencies with the request object, then maybe this bug is
> caused by the changes I've made to support the garbage collection of
> the request object, since I had to implement some traversal code that
> could fail for a reason or another.
>
> Would it be possible for you to perform the same tests with the 3.1.4
> version of mod_python.so ? We would make clear whether this is due to
> something like that.
Nicholas I can't test this in 3.1.4 because of the _pspparsestring bug (fixed in
daily snapshots) which I use extensively in my framework. However, if it's
becomes necessary to test with it I will do it no matter how much hackery it needs.
The circular dependencies I refered to were related to the fact that the
req.sess['website'] instance pointed to a Website object and that the Website
object received a call to the same req instance in one of its methods. But don't
worry, I believe this has no effect, read my next email, please.
| |
| dharana 2005-05-25, 5:46 pm |
| OFFENDING CODE
handler's code:
from mod_python import Session, apache
from ozone.storage.Storable import Storable
from ozone.websites.Website import Website
from ozone.websites.DynamicWebsite import DynamicWebsite
def handler(req):
req.sess = Session.FileSession(req)
req.sess['storable'] = Storable()
req.sess['website'] = Website()
req.sess['dynwebsite'] = DynamicWebsite()
req.sess.save()
req.write('session_id: %s' % req.sess.id())
return apache.OK
RESULT:
(see below)
COMMENT:
DynamicWebsite inherits from both Storable and Website as I told in a previous
email. I create three instances and I save them in the session.
---------------
CONTENTS OF ozone.websites.DynamicWebsite
CASE A
from ozone.storage.Storable import Storable
from ozone.websites.Website import Website
class DynamicWebsite(Storable, Website):
pass
RESULTS:
No segfault. No new session is created on each request, all three instances are
saved and retrieved correctly. It seems to work Ok.
--------------------------------------------------
CASE B
from ozone.storage.Storable import Storable
from ozone.websites.Website import Website
class DynamicWebsite(Storable, Website):
_dbschema = 'o3_websites'
RESULTS:
[notice] child pid 1695 exit signal Segmentation fault (11)
COMMENT:
Storable's __init__ calls another function that uses the _dbschema attribute to
call another function and to populate the object's attributes. Althought it's
weird (imo) that this could cause a segfault, it's weirder because the User
object (class User(Storable)) _works_ correctly if I store it in session and it
does exactly the same thing.
I hope to have made it as clear as possible. This is really weird.
Nicolas Lehuen wrote:
> Hi dharana, I have a two parts answer :
>
> 1) One thing I'm really sure is that there is no way for the pickle
> module to handle the request object correctly. Hence, if the session
> code is trying to pickle an object which contains a reference to a
> request object, I have no idea of how this can be done. This is
> another possible explanation of the segfault. Maybe you could try to
> pickle then reload an object with a reference to the request object,
> like this :
>
> import cPickle
> def index(req):
> d = { "request" : req }
> test1 = cPickle.loads(cPickle.dumps(d))
> return str(test1)
>
> In any case, storing an object with a reference to the request in a
> session is not a godd thing to do ; a request is a transient object,
> which is not meant to live for more than the request's processing
> time.
>
> 3) Another possible problem with loading pickled sessions is the case
> where you are trying to load some user-defined class instances.
>
> Due to the way pickling works, the class of an instance is saved by
> name, and the unpickling code automagically reimports the module of
> the class and rebuild the instance from there.
>
> When the class is defined in a published module (and this is also true
> for mod_python 3.1.4 and before), I can't see how the unpickling code
> can possibly find the proper published module, since the standard
> importing mechanism won't find the published module. This should raise
> a nice Python exception, but maybe with cPickle or in certain
> circumstances this causes a segmentation fault.
>
> To rule out this problem I would try to define the object class in a
> module that could be found on the PythonPath, rather than directly in
> the published module.
>
> 3) Uh oh. If you're suspecting that this problem is related to
> circular dependencies with the request object, then maybe this bug is
> caused by the changes I've made to support the garbage collection of
> the request object, since I had to implement some traversal code that
> could fail for a reason or another.
>
> Would it be possible for you to perform the same tests with the 3.1.4
> version of mod_python.so ? We would make clear whether this is due to
> something like that.
>
> Tell us if your experimentations gives some results ; I'll have a look
> at this but it is much too late for me now.
>
> Regards,
> Nicolas
>
> 2005/5/24, dharana <dharana@dharana.net>:
>
>
>
>
>
| |
| Jim Gallacher 2005-05-25, 5:46 pm |
| Nicolas Lehuen wrote:
> Hi dharana, I have a two parts answer :
>
> 1) One thing I'm really sure is that there is no way for the pickle
> module to handle the request object correctly. Hence, if the session
> code is trying to pickle an object which contains a reference to a
> request object, I have no idea of how this can be done. This is
> another possible explanation of the segfault. Maybe you could try to
> pickle then reload an object with a reference to the request object,
> like this :
>
> import cPickle
> def index(req):
> d = { "request" : req }
> test1 = cPickle.loads(cPickle.dumps(d))
> return str(test1)
I tried this and it raises a TypeError, but no segfault:
File "/srv/projects/cms/site-packages/mpdevtest/publisher.py", line
105, in handler
test1 = cPickle.loads(cPickle.dumps(d))
File "/usr/lib/python2.3/copy_reg.py", line 69, in _reduce_ex
raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle mp_request objects
A similar error is logged when trying to save a request object in a
session, so I'm thinking the problem lies elsewhere.
Regards,
Jim
> In any case, storing an object with a reference to the request in a
> session is not a godd thing to do ; a request is a transient object,
> which is not meant to live for more than the request's processing
> time.
>
> 3) Another possible problem with loading pickled sessions is the case
> where you are trying to load some user-defined class instances.
>
> Due to the way pickling works, the class of an instance is saved by
> name, and the unpickling code automagically reimports the module of
> the class and rebuild the instance from there.
>
> When the class is defined in a published module (and this is also true
> for mod_python 3.1.4 and before), I can't see how the unpickling code
> can possibly find the proper published module, since the standard
> importing mechanism won't find the published module. This should raise
> a nice Python exception, but maybe with cPickle or in certain
> circumstances this causes a segmentation fault.
>
> To rule out this problem I would try to define the object class in a
> module that could be found on the PythonPath, rather than directly in
> the published module.
>
> 3) Uh oh. If you're suspecting that this problem is related to
> circular dependencies with the request object, then maybe this bug is
> caused by the changes I've made to support the garbage collection of
> the request object, since I had to implement some traversal code that
> could fail for a reason or another.
>
> Would it be possible for you to perform the same tests with the 3.1.4
> version of mod_python.so ? We would make clear whether this is due to
> something like that.
>
> Tell us if your experimentations gives some results ; I'll have a look
> at this but it is much too late for me now.
>
> Regards,
> Nicolas
>
> 2005/5/24, dharana <dharana@dharana.net>:
>
>
>
| |
| Jim Gallacher 2005-05-25, 5:46 pm |
| dharana wrote:
> OFFENDING CODE
>
> handler's code:
>
> from mod_python import Session, apache
> from ozone.storage.Storable import Storable
> from ozone.websites.Website import Website
> from ozone.websites.DynamicWebsite import DynamicWebsite
>
> def handler(req):
> req.sess = Session.FileSession(req)
>
> req.sess['storable'] = Storable()
> req.sess['website'] = Website()
> req.sess['dynwebsite'] = DynamicWebsite()
>
> req.sess.save()
> req.write('session_id: %s' % req.sess.id())
>
> return apache.OK
>
> RESULT:
> (see below)
>
> COMMENT:
> DynamicWebsite inherits from both Storable and Website as I told in a
> previous email. I create three instances and I save them in the session.
>
>
> ---------------
>
>
>
> CONTENTS OF ozone.websites.DynamicWebsite
>
>
>
> CASE A
> from ozone.storage.Storable import Storable
> from ozone.websites.Website import Website
>
> class DynamicWebsite(Storable, Website):
> pass
>
> RESULTS:
> No segfault. No new session is created on each request, all three
> instances are saved and retrieved correctly. It seems to work Ok.
>
> --------------------------------------------------
>
> CASE B
> from ozone.storage.Storable import Storable
> from ozone.websites.Website import Website
>
> class DynamicWebsite(Storable, Website):
> _dbschema = 'o3_websites'
I wonder if _dbschema, which is a class attribute, is the problem?
Quoting from the Python documentation for pickle
(http://www.python.org/doc/2.3.5/lib/node65.html)
"""Similarly, classes are pickled by named reference, so the same
restrictions in the unpickling environment apply. Note that none of the
class's code or data is pickled, so in the following example the class
attribute attr is not restored in the unpickling environment:
class Foo:
attr = 'a class attr'
picklestring = pickle.dumps(Foo)
"""
I haven't tried any tests within mod_python, but its a good place to start.
Regards,
Jim
> RESULTS:
> [notice] child pid 1695 exit signal Segmentation fault (11)
>
> COMMENT:
> Storable's __init__ calls another function that uses the _dbschema
> attribute to call another function and to populate the object's
> attributes. Althought it's weird (imo) that this could cause a segfault,
> it's weirder because the User object (class User(Storable)) _works_
> correctly if I store it in session and it does exactly the same thing.
>
>
>
> I hope to have made it as clear as possible. This is really weird.
>
> Nicolas Lehuen wrote:
>
>
| |
| dharana 2005-05-25, 5:46 pm |
| >
>
> I wonder if _dbschema, which is a class attribute, is the problem?
> Quoting from the Python documentation for pickle
> (http://www.python.org/doc/2.3.5/lib/node65.html)
Yes, it is a class attribute.
>
> """Similarly, classes are pickled by named reference, so the same
> restrictions in the unpickling environment apply. Note that none of the
> class's code or data is pickled, so in the following example the class
> attribute attr is not restored in the unpickling environment:
Uarg.
>
> class Foo:
> attr = 'a class attr'
>
> picklestring = pickle.dumps(Foo)
> """
>
> I haven't tried any tests within mod_python, but its a good place to start.
>
But I get the segfault on the req.sess.save() line before unpickling anything
(Unless mp reloads the session after saving me, correct me if I'm wrong). Trying
to save() the dreaded object is what is causing the segfault.
Also if the class attribute isn't found it should raise an Exception on my function?
Just to clear any doubts, the class works correctly when it's not in relation to
the session. As I said previously I got around this particular segfault by
storing just the website_id.
| |
| dharana 2005-05-25, 5:46 pm |
| I am really ashamed
The error was a bug in psycopg. His author warned me a few days ago about a
severe bug that was recently fixed and urged me to sync what I didn't did until
today.
The problem was caused by DictRow objects which where stored in all my Storable
objects. I don't know the details of the psycopg bug but after synching with his
source the problem has gone away. It is also possible that the other bug, the
one happening at 30 mins intervals is algo gone for good.
I'm really sorry. I won't bother you guys until I'm dead sure it's mod_python
related and until I have a testcase for it from the beginning.
Thank you all for your help.
--
dharana
| |
| Jim Gallacher 2005-05-25, 5:46 pm |
| dharana wrote:
>
>
> Yes, it is a class attribute.
>
>
>
> Uarg.
>
>
> But I get the segfault on the req.sess.save() line before unpickling
> anything (Unless mp reloads the session after saving me, correct me if
> I'm wrong). Trying to save() the dreaded object is what is causing the
> segfault.
I'm a little unclear what you are saying here. Session.FileSession()
unpickles the session object from the session file (if the session is
valid), and save() pickles the session object and saves the pickle to
the session file.
> Also if the class attribute isn't found it should raise an Exception on
> my function?
No. The class attribute will be read from the class definition. So if
you modify your class attribute _dbschema in your code, your changes
will be lost when the instance is saved.
> Just to clear any doubts, the class works correctly when it's not in
> relation to the session. As I said previously I got around this
> particular segfault by storing just the website_id.
>
Have you tried creating a pickle of your DynWebsite object?
Regards,
Jim
|
|
|
|
|