<?xml version="1.0" encoding="utf-8" ?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Fun with ones and zeros - mod_python</title>
<subtitle>Barry&#039;s notes on computer software and hardware</subtitle>
<link href="/blog/tags/mod_python"></link>
<updated>2026-05-20T01:51:10-07:00</updated>
<id>urn:uuid:3f2a68d7-363a-26c6-75b8-04f637368227</id>
<entry>
<title>mod_python segfault fixed
</title>
<link href="/blog/entries/mod_python_segfault_3"></link>
<id>urn:uuid:fe7e44e0-0e7a-70a1-0acf-5c0dba30b15e</id>
<updated>2006-02-12T19:40:49-08:00</updated>
<author><name>Barry Pederson</name>
<email>bp@barryp.org</email>
</author>
<content type="html">
&lt;p&gt;
Just as a followup, it seems the segfault in mod_python on FreeBSD I &lt;a href=&quot;/blog/bugs/mod_python_segfault.html&quot;&gt;mentioned before&lt;/a&gt;
was &lt;a href=&quot;http://www.mail-archive.com/python-dev@httpd.apache.org/msg01062.html&quot;&gt;found&lt;/a&gt; and fixed.
Turns out to not be any kind of pointer/memory corruption like I thought, but rather a mishandled
return code from an APR (Apache Portable Runtime) function.  Oh well, I got to play with gdb, ddd, and valgrind a bit, which 
is good stuff to be familiar with.
&lt;/p&gt;



</content>
</entry>
<entry>
<title>Debugging mod_python with Valgrind
</title>
<link href="/blog/entries/mod_python_segfault_2"></link>
<id>urn:uuid:2f750a36-d564-ddab-94ef-e240cf2c7ee8</id>
<updated>2006-01-29T20:17:35-08:00</updated>
<author><name>Barry Pederson</name>
<email>bp@barryp.org</email>
</author>
<content type="html">
&lt;p&gt;
Other people have &lt;a href=&quot;http://www.mail-archive.com/python-dev@httpd.apache.org/msg01042.html&quot;&gt;reported&lt;/a&gt; 
the same problem with mod_python on FreeBSD I had seen &lt;a href=&quot;/blog/bugs/mod_python_segfault.html&quot;&gt;before&lt;/a&gt;,
so I&#039;m happy that I&#039;m not losing my mind.
&lt;/p&gt;
&lt;p&gt;
I took a stab at using &lt;a href=&quot;http://valgrind.org&quot;&gt;Valgrind&lt;/a&gt; to find the problem.  Didn&#039;t
actually find anything, but I thought I&#039;d jot down notes on how I went about this.
&lt;/p&gt;
&lt;p&gt;
First, the Valgrind port didn&#039;t seem to work on FreeBSD 6.0.  When I tried running it against the sample
code in the &lt;a href=&quot;http://valgrind.org/docs/manual/quick-start.html&quot;&gt;Valgrind Quick Start guide&lt;/a&gt;, it
didn&#039;t find anything wrong with it.  Ended up finding a FreeBSD 5.4 machine, which did see the expected problem.
&lt;/p&gt;
&lt;p&gt;
Next, I built the Apache 2.0.x port with: &lt;code&gt;make WITH_THREADS=1 WITH_DEBUG=1&lt;/code&gt;, and then built mod_python
which uses &lt;a href=&quot;http://httpd.apache.org/docs/2.0/programs/apxs.html&quot;&gt;APXS&lt;/a&gt; and picks up the debug compile option from that.
&lt;/p&gt;
&lt;p&gt;
Then, in the mod_python distribution, went into the &lt;code&gt;test&lt;/code&gt; directory, and downloaded a Valgrind suppression
file for Python, &lt;a href=&quot;http://svn.python.org/projects/python/trunk/Misc/valgrind-python.supp&quot;&gt;&lt;code&gt;valgrind-python.supp&lt;/code&gt;&lt;/a&gt;, 
and in it uncommented the suppressions for &lt;code&gt;PyObject_Free&lt;/code&gt; and &lt;code&gt;PyObject_Realloc&lt;/code&gt; (&lt;i&gt;otherwise the Valgrind output is full
of stuff that is &lt;a href=&quot;http://svn.python.org/projects/python/trunk/Misc/README.valgrind&quot;&gt;really OK&lt;/a&gt;&lt;/i&gt;). 
Then tweaked &lt;code&gt;test/test.py&lt;/code&gt; around line 307 where it starts Apache, to insert
&lt;/p&gt;
&lt;blockquote&gt;&lt;code&gt;
valgrind --tool=memcheck --logfile=/tmp/valgrind_httpd --suppressions=valgrind-python.supp
&lt;/code&gt;&lt;/blockquote&gt;
&lt;p&gt;
At the front of the &lt;code&gt;cmd&lt;/code&gt; variable that&#039;s being composed to execute httpd.
&lt;/p&gt;
&lt;p&gt;
Finally, ran &lt;code&gt;python test.py&lt;/code&gt;, and then looked at &lt;code&gt;/tmp/valgrind_httpd.pid####&lt;/code&gt; to 
see the results.
&lt;/p&gt;



</content>
</entry>
<entry>
<title>mod_python segfault on FreeBSD
</title>
<link href="/blog/entries/mod_python_segfault"></link>
<id>urn:uuid:8cc7a3fb-9dbb-7341-5874-cbb4601b2913</id>
<updated>2006-01-16T11:56:26-08:00</updated>
<author><name>Barry Pederson</name>
<email>bp@barryp.org</email>
</author>
<content type="html">
&lt;p&gt;
I&#039;ve been testing &lt;a href=&quot;http://www.modpython.org&quot;&gt;mod_python&lt;/a&gt; 3.2.x betas as 
&lt;a href=&quot;http://www.mail-archive.com/python-dev@httpd.apache.org/msg00984.html&quot;&gt;requested&lt;/a&gt;
 by the developers on their mailing list.  Unfortunately there 
seems to be some subtle memory-related but that only occurs on FreeBSD 
(or at least FreeBSD the way I normally install it along with Apache and Python).
&lt;/p&gt;
&lt;p&gt;
Made some mention of it &lt;a href=&quot;http://www.mail-archive.com/python-dev@httpd.apache.org/msg00750.html&quot;&gt;here&lt;/a&gt;
and an &lt;a href=&quot;http://issues.apache.org/jira/browse/MODPYTHON-102&quot;&gt;almost identical problem is reported for MacOSX&lt;/a&gt;, 
even down to the value &lt;code&gt;0x58&lt;/code&gt; being at the top of the backtrace.
&lt;/p&gt;
&lt;p&gt;
Did a lot of poking around the core with gdb and browsing of the mod_python 
and Apache sourcecode, but never quite saw where the problem could be.  Took another
approach and started stripping down the big mod_python testsuite, and found that the test
that was failing ran fine by itself, but when it ran after another test for handling 
large file uploads - then it would crash.  
&lt;/p&gt;
&lt;p&gt;
So I suspect there&#039;s a problem in a whole different area of mod_python, that&#039;s screwing
something up in memory that doesn&#039;t trigger a segfault til later during the connectionhandler
test.  My &lt;a href=&quot;http://www.mail-archive.com/python-dev@httpd.apache.org/msg00989.html&quot;&gt;latest post&lt;/a&gt;
to the list covers some of that.
&lt;/p&gt;



</content>
</entry>
</feed>