Bug 230127 - Loading trac through apache causes Python to segfault
Loading trac through apache causes Python to segfault
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: clearsilver (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey C. Ollie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-26 14:30 EST by Brenton D. Rothchild
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-19 16:24:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Backtrace of python crashing when loading trac through Apache/mod_python (7.22 KB, text/plain)
2007-02-26 14:30 EST, Brenton D. Rothchild
no flags Details
Backtrace of python crashing when executing trac.cgi directly by Apache without mod_python (41.37 KB, text/plain)
2007-02-26 16:48 EST, Brenton D. Rothchild
no flags Details
Fix segfault when delete a neo object (1.15 KB, patch)
2007-03-05 04:15 EST, Peng Huang
no flags Details | Diff

  None (edit)
Description Brenton D. Rothchild 2007-02-26 14:30:52 EST
Description of problem:

Loading an instance of Trac through Apache using mod_python seems to crash with
a segfault coming from Python.

Version-Release number of selected component (if applicable):

httpd-2.2.3-8
python-2.5-11.fc7
mod_python-3.3.1-3

How reproducible:
Very

Steps to Reproduce:
1. gdb /usr/sbin/httpd
2. gdb> run -X
3. Load trac (via http://localhost/cgi-bin/trac.cgi)
  
Actual results:
Browser prompts user to download file "trac.cgi"

Apache error_log says:
[Mon Feb 26 12:40:33 2007] [notice] core dump file size limit raised to
18446744073709551615 bytes
[Mon Feb 26 12:40:33 2007] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Mon Feb 26 12:40:34 2007] [notice] Digest: generating secret for digest
authentication ...
[Mon Feb 26 12:40:34 2007] [notice] Digest: done
[Mon Feb 26 12:40:34 2007] [notice] mod_python: Creating 4 session mutexes based
on 256 max processes and 0 max threads.
[Mon Feb 26 12:40:34 2007] [notice] mod_python: using mutex_directory /tmp 
[Mon Feb 26 12:40:35 2007] [notice] Apache/2.2.3 (Fedora) configured -- resuming
normal operations
[Mon Feb 26 12:41:02 2007] [notice] child pid 1432 exit signal Segmentation
fault (11), possible coredump in /tmp


Expected results:
Trac site should come up in browser

Additional info:
A backtrace from gdb is in a separate attachment.
I'm not discounting the fact that rawhide at my babies.
Comment 1 Brenton D. Rothchild 2007-02-26 14:30:52 EST
Created attachment 148820 [details]
Backtrace of python crashing when loading trac through Apache/mod_python
Comment 2 Brenton D. Rothchild 2007-02-26 14:35:03 EST
Forgot to include the version of track from rawhide:

trac-0.10.3-2.fc7
Comment 3 Jeremy Katz 2007-02-26 15:10:48 EST
Does it work if you just use it as a CGI without mod_python involved?
Comment 4 Brenton D. Rothchild 2007-02-26 16:47:25 EST
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.
Comment 5 Brenton D. Rothchild 2007-02-26 16:48:44 EST
Created attachment 148833 [details]
Backtrace of python crashing when executing trac.cgi directly by Apache without mod_python
Comment 6 Jeremy Katz 2007-02-26 17:15:16 EST
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.
Comment 7 Jeffrey C. Ollie 2007-02-26 19:05:48 EST
Has this bug been reported upstream to clearsilver?
Comment 8 Jeffrey C. Ollie 2007-02-26 19:31:09 EST
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.
Comment 9 Jeffrey C. Ollie 2007-02-27 00:46:22 EST
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/
Comment 10 Brenton D. Rothchild 2007-02-27 14:51:37 EST
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
Comment 11 Jeffrey C. Ollie 2007-02-27 15:43:29 EST
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.
Comment 12 Gwyn Ciesla 2007-02-27 16:01:46 EST
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?
Comment 13 Jeffrey C. Ollie 2007-02-27 16:24:08 EST
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...
Comment 14 Gwyn Ciesla 2007-02-28 07:16:46 EST
You meaning me or you meaning Brenton?
Comment 15 Jeffrey C. Ollie 2007-02-28 10:02:28 EST
(In reply to comment #14)
> You meaning me or you meaning Brenton?

I guess whoever can reproduce the bug, probably meaning Brenton.
Comment 16 Brenton D. Rothchild 2007-03-01 09:46:46 EST
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
Comment 17 Peng Huang 2007-03-05 02:31:30 EST
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
Comment 18 Peng Huang 2007-03-05 02:38:36 EST
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
Comment 19 Peng Huang 2007-03-05 04:15:59 EST
Created attachment 149250 [details]
Fix segfault when delete a neo object
Comment 20 Jeffrey C. Ollie 2007-04-19 16:24:11 EDT
(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. 

Note You need to log in before you can comment on or make changes to this bug.