Bug 230127

Created attachment 148820 [details]
Backtrace of python crashing when loading trac through Apache/mod_python

Forgot to include the version of track from rawhide:

trac-0.10.3-2.fc7

Does it work if you just use it as a CGI without mod_python involved?

I believe the following illustrates running the CGI without mod_python involved:

1) I moved conf.d/trac.conf to trac.conf.bak to avoid loading it

2) I changed the default httpd.conf to have TRAC_ENV set under cgi-bin,
and commented out the python_module directive:

/etc/httpd/conf/httpd.conf (relative bits):
<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
    SetEnv TRAC_ENV /opt/trac/test
</Directory>

/etc/httpd/conf.d/python.conf:
#LoadModule python_module modules/mod_python.so

3) I restarted apache via "service httpd restart"

4) I loaded http://localhost/cgi-bin/trac.cgi with a browser

At this point, the Apache error_log filled with a backtrace indicating an
invalid free() in glibc was detected.

I have attached this error_log output as another attachment.

If this isn't the right information you need, please let me know.

Created attachment 148833 [details]
Backtrace of python crashing when executing trac.cgi directly by Apache without mod_python

This is a bug in python-clearsilver.  It uses PyObject_NEW to allocate memory
and then later frees the memory with PyMem_DEL.  Although this "worked" in the
past, it's never been explicitly legal to do so and with changes to the object
system in python 2.5, it now fails spectacularly.

Fix is to replace the PyMem_DEL calls in clearsilver's python bindings with
PyObject_DEL.

Has this bug been reported upstream to clearsilver?

Apparently this bug has been fixed in version 0.10.4, which wasn't announced on
the home page:

http://www.clearsilver.net/downloads/ChangeLog.CLEARSILVER-0_10_4

I'll try and get clearsilver updated.

I've built some new RPMS... Let me know if they solve the problem and I'll
commit the changes.

http://repo.ocjtech.us/misc/fedora/development/x86_64/

I tried python-clearsilver-0.10.4-1.fc7.x86_64.rpm.

Trac loads fine through a regular CGI.

Trac still seems to crash python when using mod_python and has an identical
backtrace to the first attachement,
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148820

This issue probably needs to be taken upstream with the ClearSilver developers.
 I don't know enough about the internals of Python, mod_python, and httpd to be
of much help debugging.

I don't see an obvious bug-tracking system for upstream.  Will you be posting
the results of your contact with upstream in this bug?

No, you need to take it upstream, as I don't have the resources to duplicate the
problem (I don't have a box running development).  They do appear to have a
yahoo groups mailing list.  I had also looked for a public source code
repository but didn't see one.  If I had found one I would have looked to see if
there were any fixes in the repository that hadn't made it into a release...

You meaning me or you meaning Brenton?

(In reply to comment #14)
> You meaning me or you meaning Brenton?

I guess whoever can reproduce the bug, probably meaning Brenton.

I have posted to the ClearSilver Yahoo! group to see if I can get more
information regarding this bug.

http://tech.groups.yahoo.com/group/ClearSilver/message/925

I use trac as standalone mode. The python will segfault too.
[phuang@dhcp-0-143 trac]$ /usr/sbin/tracd -p 8000 --auth '*',passwd,trac project1/
*** glibc detected *** /usr/bin/python: munmap_chunk(): invalid pointer:
0xb7ef6380 ***
======= Backtrace: =========
/lib/libc.so.6(cfree+0x1bb)[0x44b2dd6b]
/usr/lib/python2.5/site-packages/neo_cgi.so[0x472634]
/usr/lib/libpython2.5.so.1.0[0x45a2e76a]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x483)[0x45a90873]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x5419)[0x45a8edd9]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x5419)[0x45a8edd9]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x5419)[0x45a8edd9]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x45a8fd8f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0[0x45a2feca]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0[0x45a183f8]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0[0x45a5ec59]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x3611)[0x45a8cfd1]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0[0x45a2feca]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0[0x45a183f8]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0[0x45a5ec59]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x3611)[0x45a8cfd1]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x45a8fd8f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x45a8fd8f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x45a8fd8f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0[0x45a2feca]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0[0x45a183f8]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0(PyEval_CallObjectWithKeywords+0x7c)[0x45a88d9c]
/usr/lib/libpython2.5.so.1.0(PyInstance_New+0x6d)[0x45a1c0fd]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x3611)[0x45a8cfd1]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x45a8fd8f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0[0x45a2ffa0]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x42f5)[0x45a8dcb5]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x63cf)[0x45a8fd8f]
/usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7ef)[0x45a90bdf]
/usr/lib/libpython2.5.so.1.0[0x45a2feca]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0[0x45a183f8]
/usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37)[0x45a10ef7]
/usr/lib/libpython2.5.so.1.0(PyEval_CallObjectWithKeywords+0x7c)[0x45a88d9c]
/usr/lib/libpython2.5.so.1.0[0x45ab83d4]
/lib/libpthread.so.0[0x44e552db]
/lib/libc.so.6(clone+0x5e)[0x44b91d3e]
======= Memory map: ========
00110000-00111000 r-xp 00000000 08:08 1988879   
/usr/lib/python2.5/lib-dynload/_weakref.so
00111000-00112000 rwxp 00000000 08:08 1988879   
/usr/lib/python2.5/lib-dynload/_weakref.so
00112000-00120000 r-xp 00000000 08:08 1988889   
/usr/lib/python2.5/lib-dynload/datetime.so
00120000-00123000 rwxp 0000d000 08:08 1988889   
/usr/lib/python2.5/lib-dynload/datetime.so
00127000-0012c000 r-xp 00000000 08:08 1988887   
/usr/lib/python2.5/lib-dynload/collectionsmodule.so
0012c000-0012d000 rwxp 00005000 08:08 1988887   
/usr/lib/python2.5/lib-dynload/collectionsmodule.so
0012d000-0014b000 r-xp 00000000 08:08 2541276   
/usr/lib/python2.5/site-packages/libsvn/_fs.so
0014b000-0014e000 rwxp 0001d000 08:08 2541276   
/usr/lib/python2.5/site-packages/libsvn/_fs.so
0014e000-00155000 r-xp 00000000 08:08 1521601    /usr/lib/libsvn_diff-1.so.0.0.0
00155000-00156000 rwxp 00007000 08:08 1521601    /usr/lib/libsvn_diff-1.so.0.0.0
00169000-0016a000 r-xp 00000000 08:08 1988849   
/usr/lib/python2.5/lib-dynload/_bisect.so
0016a000-0016b000 rwxp 00001000 08:08 1988849   
/usr/lib/python2.5/lib-dynload/_bisect.so
0016b000-0019e000 r-xp 00000000 08:08 1521623    /usr/lib/libsvn_wc-1.so.0.0.0
0019e000-0019f000 rwxp 00032000 08:08 1521623    /usr/lib/libsvn_wc-1.so.0.0.0
001b4000-001b8000 r-xp 00000000 08:08 521254     /lib/libnss_dns-2.5.90.so
001b8000-001b9000 r-xp 00003000 08:08 521254     /lib/libnss_dns-2.5.90.so
001b9000-001ba000 rwxp 00004000 08:08 521254     /lib/libnss_dns-2.5.90.so
001ba000-001e1000 r-xp 00000000 08:08 423494     /usr/lib/libapr-1.so.0.2.8
001e1000-001e2000 rwxp 00027000 08:08 423494     /usr/lib/libapr-1.so.0.2.8
001f6000-00206000 r-xp 00000000 08:08 1988884   
/usr/lib/python2.5/lib-dynload/cPickle.so
00206000-00207000 rwxp 00010000 08:08 1988884   
/usr/lib/python2.5/lib-dynload/cPickle.so
00207000-0026c000 r-xp 00000000 08:08 1988915   
/usr/lib/python2.5/lib-dynload/unicodedata.so
0026c000-0027b000 rwxp 00065000 08:08 1988915   
/usr/lib/python2.5/lib-dynload/unicodedata.so
0027b000-00295000 r-xp 00000000 08:08 1521611    /usr/lib/libsvn_ra_dav-1.so.0.0.0
00295000-00296000 rwxp 0001a000 08:08 1521611    /usr/lib/libsvn_ra_dav-1.so.0.0.0
0029a000-0029c000 r-xp 00000000 08:08 1990840   
/usr/lib/python2.5/lib-dynload/_heapq.so
0029c000-0029e000 rwxp 00002000 08:08 1990840   
/usr/lib/python2.5/lib-dynload/_heapq.so
0029e000-002c7000 r-xp 00000000 08:08 1521605    /usr/lib/libsvn_fs_base-1.so.0.0.0
002c7000-002c8000 rwxp 00028000 08:08 1521605    /usr/lib/libsAborted

The simple python code that is listed below will cause python to segfault. Hope
it  would be useful for debug it.

=====
#!/usr/bin/env python
import neo_cgi
a = neo_cgi.CGI()
a = neo_cgi.CGI()
print a

Created attachment 149250 [details]
Fix segfault when delete a neo object

(In reply to comment #19)
> Created an attachment (id=149250) [edit]
> Fix segfault when delete a neo object
> 

This fix is already in 0.10.4, which has been in extras for a while.  I'm going
to close this report, feel free to open it back up if there is still a problem.