Retrieving a changeset results in an empty page

[Christian Boos]

I was trying to get a changeset page, but instead I got an empty page (0 bytes), no error.

That was for Markup:changeset:104, but I don't think the changeset module is the culprit, I guess it could have happened with another page as well. It's not the first time I'm seeing this, hence the ticket.

Too bad I didn't have LiveHTTPHeaders running, but at least I looked for the server status immediately after the "error", so it can be possible to retrieve something in the log.

Apache Server Status for www.edgewall.org
...

Current Time: Saturday, 22-Jul-2006 12:14:51 CDT
Restart Time: Wednesday, 19-Jul-2006 16:20:44 CDT
...
CPU Usage: u163.71 s13.69 cu2.04 cs0 - .0734% CPU load
2.71 requests/sec - 33.7 kB/second - 12.4 kB/request
3 requests currently being processed, ...

Srv	PID	Acc	M	CPU 	SS	Req	Conn	Child	Slot	Client	VHost	Request
...
17-0	-	0/0/37114	. 	2.62	8	0	0.0	0.00	435.85 	84.101.83.196	markup.edgewall.org	GET /changeset/104 HTTP/1.1

[Christian Boos]

Aha! It just happened again with Markup:changeset:105, but this time I had the LiveHTTPHeaders running; here's what it shows:

http://markup.edgewall.org/changeset/105

GET /changeset/105 HTTP/1.1
Host: markup.edgewall.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://markup.edgewall.org/changeset/104
Cookie: trac_session=2ad6a6d00e649d3fcedd9071

HTTP/1.x 200 OK

[Christian Boos]

Just happened again one minute ago while previewing a ticket comment. URL was http://trac.edgewall.org/ticket/3459#preview. Maybe there's something in the log, now.

[Christian Boos]

Just went through the last dozen of changesets in Markup, and it was really one request out of 2 that resulted in an empty page. Reloading the page didn't work all the times the first time, sometimes I needed to reload 3 times before getting something. Sometimes reloading a page that was already seen also resulted in the empty page, so in that case, it must be a problem before we go into check_modified.

I had the problem indiferently with Firefox (empty page displayed) or IE (Page can't be displayed) error. I was not logged in.

Activity on the server was low. I noticed this:

Srv	PID	Acc	M	CPU 	SS	Req	Conn	Child	Slot	Client	VHost	Request
3-0	-	0/0/9500	. 	1.04	6	0	0.0	0.00	132.42 	194.173.12.131	markup.edgewall.org	GET /changeset/101 HTTP/1.1
4-0	671	0/14/9671	_ 	2.61	7	28	0.0	0.17	131.92 	194.173.12.131	markup.edgewall.org	GET /changeset/103 HTTP/1.1
5-0	629	0/35/9743	_ 	10.72	8	121	0.0	0.86	131.57 	194.173.12.131	markup.edgewall.org	GET /changeset/104 HTTP/1.1

3-0 was a faulty request and it has no PID. Does that mean the process died?

Is there really nothing in the logs?

[Christian Boos]

Summarizing some progress this issue has seen today:

There were indeed tons of segfaults recorded in the Apache error.log. This is since the introduction of virtual hosts, so this might be related to #2611/#2965, though the SVN bindings used so far were 1.1.4 and switching to 1.2.3 didn't help.

[Jonas Borgström]

It appears that forcing mod_python to use the same python interpreter for all virtual hosts solves the problem. Adding the following line to each virtual host on edgewall.org solved the problem:

PythonInterpreter "trac"

My current theory is that the subversion python bindings somehow does not like the way mod_python uses multiple python interpreters. It could also be that we do not call apr_initialize()/apr_terminate() correctly.

[Christian Boos]

Great! So without the "PythonInterpreter" directive, mod_python was using different interpreters for different virtual hosts by default; I didn't know that, but it's true that it's well documented, e.g. from ​Mod_python Manual 4.1:

Default behaviour is to name interpreters using the Apache virtual server name (ServerName directive). This means that all scripts in the same virtual server execute in the same subinterpreter, but scripts in different virtual servers execute in different subinterpreters with completely separate namespaces.

This is a bit unfortunate for us, as it's apparently a well-known source of problems with extensions: see ​Py_NewInterpreter, look for Bugs and caveats.

So that solution might also cure the #2611 issue… have you tried? (I'm asking because you said you were able to reproduce that issue while using the 1.3.2 bindings)

[synace]

adding the following to my vhosts

PythonInterpreter "trac"

works for me on FreeBSD 6.0, SVN 1.3.0, Trac 0.9.3, Apache 2.2.0, mod_python 3.1.5, Python 2.4.2

was getting

"argument number 0: a 'apr_pool_t *' is expected"

and

child pid XXXXX exit signal Segmentation fault (11)

[trac@…]

Seems to work nicely for me, as well, on Windows XP with Trac 0.10b1 + Apache/2.0.55 (Win32) DAV/2 mod_python/3.2.10 Python/2.4.3 mod_ssl/2.0.55 OpenSSL/0.9.8a SVN/1.4.0

[Graham Dumpleton]

If using mod_python 3.2.8 or later, rather than use an interpreter called 'trac' you might be better off using:

PythonInterpreter main_interpreter

The 'main_interpreter' in mod_python 3.2.8 and later is guaranteed to be the first Python interpreter instance which was created by mod_python. The first interpreter instance is special in that it is the only one that will usually work reliably for third party extensions which use the simplified PyGILState_* API functions. If not used, such third party extensions may crash, or give 'not accessible in restricted mode' Python exceptions. Thus, to be absolutely safe, use it instead.

Some discussion on this issue in mod_python can be found at:

​http://issues.apache.org/jira/browse/MODPYTHON-77

[anonymous]

Replying to trac@digidescorp.com:

Seems to work nicely for me, as well, on Windows XP with Trac 0.10b1 + Apache/2.0.55 (Win32) DAV/2 mod_python/3.2.10 Python/2.4.3 mod_ssl/2.0.55 OpenSSL/0.9.8a SVN/1.4.0

This resolved my issue as it was outlined in ​http://trac.edgewall.org/ticket/2611 here is the software I'm using:

2.4.26-gentoo-r9 apache-2.0.58-r2 subversion-1.4.2 python-2.4.3-r4 mod_python-3.1.4-r1 swig-1.3.25 trac-0.10.3

So Im' not sure if this helps, but it help me so thanks!

[sphe@…]

If you're running multiple instances under mod_wsgi, setting:

WSGIApplicationGroup %{GLOBAL}

effectively forces the instance to run in main interpreter and resolves the issue