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 <[EMAIL PROTECTED]>:
> 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.
> >
>
> --
> dharana
>
>
