[issue1758146] Crash in PyObject_Malloc
Terry J. Reedy tjre...@udel.edu added the comment: Is this still an issue for 2.7 or 3.x? Is it actually a Python issue or should it be closed? -- nosy: +tjreedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Graham Dumpleton graham.dumple...@gmail.com added the comment: The actual reported problem was likely because of known issues with running subversion Python wrappers in a sub interpreter. The rest of the conversation was for a completely different issue which relates to mod_python not using thread APIs in Python in the required manner. In both cases it is a package distinct from Python itself. The only fault in Python is the inadequate documentation describing the intricacies of using threading APIs in Python, especially in relation to sub interpreters and also user created thread state objects against main interpreter. As far as the original issue is concerned however, issue should be able to be closed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Terry J. Reedy tjre...@udel.edu added the comment: OK. If Graham or anyone has concrete suggestions for improving the current 3.2a1 doc for threading, open a fresh issue. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Graham Dumpleton [EMAIL PROTECTED] added the comment: I do understand. The initial thread, which is effectively a foreign thread to Python to begin with, when used to initialise Python, ie., call Py_Initialize(), is treated in a special way in as much as as a side effect it does that initialisation of GIL internal thread state. This is as you say. But, this is the only foreign thread this implicitly occurs for and why the main thread is a bit special. If you were to create additional foreign threads outside of Python, ie., in addition to main thread which initialised it, those later threads should not fail the Py_DEBUG test unless the code they execute explicitly calls the simplified API and by doing so implicitly causes internal threadstate for that thread to be created. Hope this makes sense. Sorry, in a bit of a hurry. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Graham Dumpleton [EMAIL PROTECTED] added the comment: Franco, you said 'I found that you cannot create additional thread states against the first interpreter and swap between them w/o this assertion occurring. ...' Since the Py_DEBUG check is checking against the simplified GIL state API thread state object, then technically you could have a thread with multiple thread states, that thread just can't ever use/have used simplified GIL state API. Take for example a system where threads are actually foreign threads and not created within Python. In this case simplified GIL state API thread state object would never have been created for that thread. For those you could have multiple thread states and not trip the test. In other words, multiple thread states only blocked if one of them is the internal one created by simplified GIL state AP. This is getting hard to avoid though. In summary, the simplified GIL state API is basically viral in nature. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Graham Dumpleton [EMAIL PROTECTED] added the comment: I know the discussions more or less says this, but I want to add some additional information. For the record, the reason that mod_python crashes with 'Invalid thread state for this thread' when Py_DEBUG is defined in part relates to: http://issues.apache.org/jira/browse/MODPYTHON-217 Also, that Py_DEBUG check effectively says that if you use simplified GIL API for a particular thread against the first interpreter, you are prohibited from creating additional thread states for that thread. I haven't checked the documentation lately, but I am not sure it is really clear on that specific point and so in some respects the documentation may be at fault here. Someone might like to point to exact part of documentation which states this requirement. The problem thus is that code which worked prior to Python 2.3 would still work with Python 2.3 and later, up to the point that some code decided to use the simplified GIL API. At that point Python would create its own internal thread state for that thread even if user code had already created one. Conversely, if the simplified GIL API was used against the thread first and then user code tried to create an additional thread state for that thread against first interpreter. With Py_DEBUG defined, this scenario causes the assertion failure and the above error. Without Py_DEBUG defined, the code can quite happily run fine, at least until the point where code which left Python using a user thread state object attempts to reenter Python by using simplified GIL API. At that point it would deadlock. Now, as I said, that one was effectively forced to use simplified GIL API for first interpreter with Python 2.3 probably wasn't at all clear and so mod_python was never updated to meet that requirement. As per the JIRA issue referenced above it is a known problem that code isn't meeting this requirement, but not much development has been done on mod_python for quite a while. I have though recently made changes to personal copy of mod_python code such that it uses simplified GIL API for all access against first interpreter and it no longer suffers that assertion failure when Py_DEBUG defined. The code also should work for any modules which use simplified GIL API, such as SWIG generated bindings for Xapian. You do have to force the application using such modules to run under first interpreter. The code for mod_wsgi uses simplified GIL API for first interpreter as well and works with SWIG generated bindings, but it is possible that it may still fail that assertion when Py_DEBUG is defined. This is because in order to allow mod_python and mod_wsgi to be used in Apache at the same time, mod_wsgi had to incorporate some hacks to workaround the fact that mod_python was not using simplified GIL API for first interpreter, but also because mod_python wasn't releasing the GIL for a critical section between when it was initialised and Apache child processes were created. It was in this section that mod_wsgi has to initialise itself and so it had to fiddle the thread states to be able to do its things. This workaround may have been enough to create additional thread state of a thread for first interpreter, thus later triggering the assertion. It would have been nice to have mod_wsgi do the correct thing from the start, but that would have barred it being used at same time as mod_python and so people may have baulked at trying mod_wsgi as a result. Now that mod_wsgi has got some traction, in mod_wsgi version 3.0 it will be changed to remove the mod_python fiddle. This will mean that mod_wsgi 3.0 will not be usable at same time as current mod_python versions and would only be usable with the mod_python version (maybe 3.4) which I have made modifications for to also use simplified GIL APIs properly. So that is the state of play as I see and understand it. As to Adam's comments about use cases for multiple interpreters, we have had that discussion before and despite that many people rely on that feature in both mod_python and mod_wsgi he still continues to dismiss it outright and instead calls for complete removal of the feature. Also Adam's comments that multiple interpreters were used in mod_wsgi only to support buggy third party software, that is untrue. Multiple interpreter support exists in mod_wsgi because mod_python provided a similar feature and mod_python existed before many of the Python web applications which are claimed to be the reason that sub interpreters are used in the first place. So, mod_python and use of sub interpreters came first, and not really the other way around. Where Python web applications do rely on os.environ it is historically because that is how things were done in CGI. Many such as Trac may still support that means of configuration as a fall back, but Trac now also supports other ways which are thread safe. All up, use of distinct sub
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: Also, that Py_DEBUG check effectively says that if you use simplified GIL API for a particular thread against the first interpreter, you are prohibited from creating additional thread states for that thread. I found that you cannot create additional thread states against the first interpreter and swap between them w/o this assertion occurring. I didn't use the GIL functions at all and had this issue in debug. PyInitialize initializes the GIL and hijacks the main interpreter. We always call PyInitialize so does that mean we can only use the GIL functions with the main interpreter and nothing else when locking/unlocking the global lock as you seem to infer? Does that mean there is a backward compatibility issue here with those who used the main interpreter only and created thread states from it to handle multi- threading, like I did (thru the use of PyEval_Acquire/Release PyThreadState_Swap)? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: By the way. I switched to using the GIL functions on the main interpreter and everything works great now. It is a better solution to use the GIL functions because I also had my own code that prevented dead lock from occuring when a python script calls back into the extension module that ends up calling PyEval_Acquire again (deadlock) even though it is the same thread. Now with the GIL functions I don't need that code. It is a good feature but it broke my previous implementation and it is not obvious why. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Graham, I appreciate the history of sub-interpreters and how entrenched they are. Changing those practises requires a significant investment. This is an important factor to consider. The other factor is the continuing maintenance and development cost. Subinterpreters add substantial complexity, which I can personally vouch for. This is exhibited in the GIL API not supporting them properly and in the various bugs that have been found over the years. Imagine, for a moment, that the situation were reversed; that everything were built on threading. Would you consider even for a moment adding sub-interpreters? How could you justify it? It's not a decision to be taken lightly, but my preference is clear: bite the bullet, make the change. It's easier in the long run. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: OK, I think I found my problem. I was using the main interpreter state (the one created by Py_Initialize) to create new thread states with. It seems that this interpreter state is reserved for GIL functions so one will need to create a new interpreter state with PyInterpeterState_New and use that interpreter state when creating the cooperating threads. So now this check makes sense. If one is swapping in a ts belonging to the main interpreter state, it best be the GIL thread state. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Apparently modwsgi uses subinterpreters because some third-party packages aren't sufficiently thread-safe - modwsgi can't fix those packages, so subinterpreters are the next best thing. http://groups.google.com/group/modwsgi/browse_frm/thread/988bf560a1ae8147/2f97271930870989 This is a weak argument for language design. Subinterpreters should be deprecated, the problems with third-party packages found and fixed, and ultimately subinterpreters ripped out. If you wish to improve the situation, I suggest you help fix the problems in the third-party packages. For example, http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac implies trac is configured with environment variables - clearly not thread-safe. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Vaclav Slavik [EMAIL PROTECTED] added the comment: I'm sorry, did you actually read my comments? Once again, this has nothing to do with threads and everything to do with isolation of independent Python apps running in the same *process*. Hope it got through this time :-/ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Ahh, I did miss that bit, but it doesn't really matter. Tell modwsgi to only use the main interpreter (PythonInterpreter main_interpreter), and if you want multiple modules of the same name put them in different packages. Any other problems (trac using env vars for configuration) should be fixed directly. (My previous comment about building your own import mechanism was overkill. Writing a package that uses relative imports is enough - in fact, that's what relative imports are for.) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: I believe PyThreadState_Swap function in ceval.c has a bug as I stated earlier. However, I have not seen it included in the latest patches so now I wonder... The following line in PyThreadState_Swap... if (check check-interp == newts-interp check != newts) should read as follows... if (check check-interp != newts-interp check != newts) since this condition, if true, raises an error. Why should it raise an error if all the interpreters are equal across multiple thread states? If we have one interpreter with multiple thread states (i.e. multi- threaded application) this function will error when switching between the thread states within the same interpreter (in DEBUG compile mode only since this code is commented out otherwise). In the forums it describes the use of thread states to handle multiple python threads running simultaneously and not by using multiple interpreters but only one (the main interpreter). Also the interpreters have be equal because in the documentation for the GIL functions it says it doesn't support multiple interpreters. I think this is a typo/bug in the code. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Franco, you need to look at the line above that check: PyThreadState *check = PyGILState_GetThisThreadState(); if (check check-interp == newts-interp check != newts) Py_FatalError(Invalid thread state for this thread); PyGILState_GetThisThreadState returns the original tstate *for that thread*. What it's asserting is that, if there's a second tstate *in that thread*, it must be in a different subinterpreter. It doesn't prevent your second and third tstate from sharing the same subinterpreter, but it probably should, as this check implies it's an invariant. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: Thanks Adam but I'm still confused because... There is a new rule in version 2.3.5. Which is one interpreter with many thread states are supported for the GIL functions. So this code breaks that rule since this if statement is checking if the interpreters are different for the current GIL state and the new ts which it can't be (i.e. unsupported). See this email that points to the python documentation for 2.3.5 regarding this new rule... http://mail.python.org/pipermail/python-dev/2005-May/053840.html Here is the extract of the email pertaining to this issue... The documentation (http://docs.python.org/api/threads.html) states Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. , so it looks like that using the PyGilState_XXX functions in the core threadmodule.c means the Py_NewInterpreter() call (i.e. multiple interpreters) is no longer supported when threads are involved. So regardless if we use the GIL functions or the lower level functions it all eventually boils down to this Swap function which has this condition that doesn't match what the documentation is stating. So which way is it? Can't have it both ways. It seems since 2.3.5 they don't want you to use multiple interpreters is my guess when threading is involved. - Franco - Original Message - From: Adam Olsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 6:25 PM Subject: [issue1758146] Crash in PyObject_Malloc Adam Olsen [EMAIL PROTECTED] added the comment: Franco, you need to look at the line above that check: PyThreadState *check = PyGILState_GetThisThreadState(); if (check check-interp == newts-interp check != newts) Py_FatalError(Invalid thread state for this thread); PyGILState_GetThisThreadState returns the original tstate *for that thread*. What it's asserting is that, if there's a second tstate *in that thread*, it must be in a different subinterpreter. It doesn't prevent your second and third tstate from sharing the same subinterpreter, but it probably should, as this check implies it's an invariant. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: Thanks Adam but I'm still confused because... There is a new rule in version 2.3.5. Which is one interpreter with many thread states are supported for the GIL functions. So this code breaks that rule since this if statement is checking if the interpreters are different for the current GIL state and the new ts which it can't be (i.e. unsupported). See this email that points to the python documentation for 2.3.5 regarding this new rule... http://mail.python.org/pipermail/python-dev/2005-May/053840.html Here is the extract of the email pertaining to this issue... The documentation (http://docs.python.org/api/threads.html) states Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. , so it looks like that using the PyGilState_XXX functions in the core threadmodule.c means the Py_NewInterpreter() call (i.e. multiple interpreters) is no longer supported when threads are involved. So regardless if we use the GIL functions or the lower level functions it all eventually boils down to this Swap function which has this condition that doesn't match what the documentation is stating. So which way is it? Can't have it both ways. It seems since 2.3.5 they don't want you to use multiple interpreters is my guess when threading is involved. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: It's only checking that the original tstate *for the current thread* and the new tstate have a different subinterpreter. A subinterpreter can have multiple tstates, so long as they're all in different threads. The documentation is referring specifically to the PyGILState_Ensure and PyGILState_Release functions. Calling these says I want a tstate, and I don't know if I had one already. The problem is that, with subinterpreters, you may not get a tstate with the subinterpreter you want. subinterpreter references saved in globals may lead to obscure crashes or other errors - some of these have been fixed over the years, but I doubt they all have. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Vaclav Slavik [EMAIL PROTECTED] added the comment: This could be done either by not using the normal import mechanism This is completely unrealistic suggestion, people use libraries and frameworks in their code, you're in effect suggestion that no library that could possibly be used in webapp should use (standard) import. I may be wrong, but I strongly suggest that you do talk to mod_python/wsgi people (who know much better than me) about what real-life uses of isolated interpreters are, before entertaining the idea of getting rid of the feature. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Does the PythonInterpreter option create multiple interpreters within a single process, rather than spawning separate processes? IMO, that API should be ripped out. They aren't truly isolated interpreters and nobody I've asked has yet provided a use case for it. -- nosy: +Rhamphoryncus ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Vaclav Slavik [EMAIL PROTECTED] added the comment: Does the PythonInterpreter option create multiple interpreters within a single process Yes. They aren't truly isolated interpreters and nobody I've asked has yet provided a use case for it. If you ignore mod_python and mod_wsgi, then maybe, but mod_python is *the* use case for this. Running separate process for every web app and/or every virtual host on your server is expensive in terms of RAM usage (and this matters if you use virtual server - 256MB or less is not unusual). On the other hand, you need isolation for independent apps -- some modules may use globals, or you may want to be able to run both production and testing versions of the same app (i.e. different versions of the same Python module). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Right, so it's only the python modules loaded as part of the app that need to be isolated. You don't need the stdlib or any other part of the interpreter to be isolated. This could be done either by not using the normal import mechanism (build your own on top of exec()) or by some magic to generate a different root package for each interpreter (so you show up in sys.modules as '_mypkg183.somemodule'.) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- type: - crash ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: The documentation states that thread states are supported within a single interpreter and not supported across other interpreters (specifically for the GIL functions which are just wrapper functions around the PyEval_ functions). So I would have to conclude then that the condition should check to see if the swapping thread is within the current interpreter state otherwise fatal error, as such... The condition: check-interp == newts-interp should be: check-interp != newts-interp In otherwords if there is a previous thread state and it's interpreter is NOT the same as the one being swapped in then do the fatal error. Just my opinion. I ran into this problem when using the PyThreadState_Swap function directly (low level) to do the thread handling within a single interpreter state (Debug mode only). -- nosy: +fdirosa ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Vaclav Slavik [EMAIL PROTECTED] added the comment: I'm able to reliably reproduce this bug (using Apache 2.2.8, otherwise same as above), although not with mod_python's simple tests, but only with Trac (apparently, Trac creates some threads while processing the request). How to reproduce: configure two Trac/mod_python locations in Apache config and set them to use different Python interpreters: Location /trac1 SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnv /srv/bakefile/trac PythonOption TracUriRoot / PythonInterpreter trac1 /Location Location /trac2 SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnv /srv/bakefile/trac PythonOption TracUriRoot / PythonInterpreter trac2 /Location (As far as this bug is concerted, this is the same as having two virtual hosts that both run Trac -- mod_python's default interpreter has the same name as the (virtual) host.) Then run Apache as apache2 -X to ensure that requests are handled by single handler serially and do $ curl http://your-server/trac1/wiki $ curl http://your-server/trac2/wiki The second command crashes Apache. If you change mod_python configuration to use the same interpreter names for both Trac instances, the crash doesn't happen (but of course, that prevents you from using different versions of Python modules in both vhosts). I'm attaching Valgrind log, but it's not very useful -- it's not deep enough and my server doesn't have enough memory for high enough value of --num-callers. -- nosy: +vslavik Added file: http://bugs.python.org/file10393/valgrind.log.gz _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
