You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Peter Hawkins <pe...@hawkins.emu.id.au> on 2002/09/22 07:57:07 UTC
Segfault in 2.7.8
Hi...
I'm the current debian package maintainer for mod_python.
I'm hoping that someone can help me with this bug (the bugs listed
below are identical, I think).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152750&repeatmerged=yes
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135346&repeatmerged=yes
As explained in the bug logs, if you change your encoding to anything
other than ascii in /etc/python2.1/site.py, then mod_python segfaults
on every request. Somehow, this causes the interpreters global
variable to be NULL when it is used in get_interpreter_data, leading
to a segfault. Other people have reported a similar problem with
different site customisations (eg. adding rlcompleter).
The python versions that modpython is built against (2.1, 2.2 and
2.3a0) are all compiled with threads on linux (not really an awful
lot I can do about that).
There are a couple of (possibly) odd things the package is doing. The
first is that we are linking against libpython*.so, (ie. dynamically,
not statically). I am wondering whether this is causing the problem.
A little debugging has shown me that the second time python_init is
called, Py_IsInitialized returns TRUE, even though the interpreters
global variable is NULL. Is this something wierd happening with the
fact that python is a shared, not a static library?
Backtrace (my own):
0x40280424 in PyDict_GetItemString () from
/usr/lib/libpython2.2.so.0.0
(gdb) bt
#0 0x40280424 in PyDict_GetItemString () from
/usr/lib/libpython2.2.so.0.0
#1 0x4022e1a6 in get_interpreter_data () from
/usr/lib/apache/1.3/mod_python.so
#2 0x4022f0f4 in make_obcallback () from
/usr/lib/apache/1.3/mod_python.so
#3 0x402306f0 in python_finalize () from
/usr/lib/apache/1.3/mod_python.so
#4 0x08053a84 in ap_invoke_handler ()
#5 0x0806338c in ap_some_auth_required ()
#6 0x080633e8 in ap_process_request ()
#7 0x0805cbcb in ap_child_terminate ()
#8 0x0805cd5c in ap_child_terminate ()
#9 0x0805ce79 in ap_child_terminate ()
#10 0x0805d355 in ap_child_terminate ()
#11 0x0805da5d in main ()
#12 0x400ed0bf in __libc_start_main () from /lib/libc.so.6
From the bug logs:
(gdb) bt
#0 0x40438989 in PyDict_GetItem () from /usr/lib/libpython2.1.so.0.0
#1 0x4043a051 in PyDict_GetItemString () from
/usr/lib/libpython2.1.so.0.0
#2 0x403bb1a6 in get_interpreter_data (name=3D0x80d9a0c
"jt5-223b.tky.hut.=
fi",
srv=3D0x808898c) at mod_python.c:117
#3 0x403bc0f4 in python_handler (req=3D0x813055c,
handler=3D0x403c1b4b "PythonHandler") at mod_python.c:633
#4 0x403bd6d0 in PythonHandler (req=3D0x813055c) at mod_python.c:1438
#5 0x08053a44 in ap_invoke_handler ()
#2 0x403bb1a6 in get_interpreter_data (name=3D0x80d9a0c
"jt5-223b.tky.hut.=
fi",
srv=3D0x808898c) at mod_python.c:117
117 p =3D PyDict_GetItemString(interpreters, (char *)name);
(gdb) p interpreters
$1 =3D (PyObject *) 0x0
Any ideas?
Thanks,
Peter
peterh@debian.org
--
peter@hawkins.emu.id.au
GPG key fingerprint:
C746 38A9 D3E4 A171 FB6A 56D4 5E30 DFCC BE11 F437
Re: another beta and dist files now on www.apache.org
Posted by Gary Benson <gb...@redhat.com>.
On Tue, Sep 24, 2002 at 01:17:44PM -0400, grisha@apache.org wrote:
> Also put another tarfile of a current CVS snapshot out there. We should
> really write a script to do it automatically.
I case you want it, the attached is what I've been using for the job.
Just run ./mktarball.sh and it'll build a tarball including the HTML
docs and excluding all the CVS stuff.
It lives in the following heirachy:
mod_python/ - a checked out copy of mod_python
build/Python-2.1.tgz - an unmodified Python tarball
mktarball.sh - the attached script
Later,
Gary
[ gbenson@redhat.com ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
another beta and dist files now on www.apache.org
Posted by gr...@apache.org.
Just FYI -
moved all the dist files to http://www.apache.org/dist/httpd/modpython/
I'm not so sure about what the structure of distribution directories
should be, but given the currently ongoing reorg, it probably doesn't make
too much sense to reinvent it, so I just copied everything as it was
originally on modpython.org.
I was also somewhat undecided between calling the directory modpython vs
mod_python, in the end decided on modpython.
Also put another tarfile of a current CVS snapshot out there. We should
really write a script to do it automatically.
Grisha
Re: Segfault in 2.7.8
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Which encoding are you using? I tried a couple with latest CVS of
mod_python 3.0 and it didn't segfault. I tried koi8-r, iso-8859-15 and
utf-7, and it didn't crash - but I'm not sure if this means that 3.0 has
this now fixed, or I didn't test it thoroughly enough.
Grisha
On Sun, 22 Sep 2002, Peter Hawkins wrote:
> Hi...
>
> I'm the current debian package maintainer for mod_python.
>
> I'm hoping that someone can help me with this bug (the bugs listed
> below are identical, I think).
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152750&repeatmerged=yes
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135346&repeatmerged=yes
>
> As explained in the bug logs, if you change your encoding to anything
> other than ascii in /etc/python2.1/site.py, then mod_python segfaults
> on every request. Somehow, this causes the interpreters global
> variable to be NULL when it is used in get_interpreter_data, leading
> to a segfault. Other people have reported a similar problem with
> different site customisations (eg. adding rlcompleter).
>
> The python versions that modpython is built against (2.1, 2.2 and
> 2.3a0) are all compiled with threads on linux (not really an awful
> lot I can do about that).
>
> There are a couple of (possibly) odd things the package is doing. The
> first is that we are linking against libpython*.so, (ie. dynamically,
> not statically). I am wondering whether this is causing the problem.
> A little debugging has shown me that the second time python_init is
> called, Py_IsInitialized returns TRUE, even though the interpreters
> global variable is NULL. Is this something wierd happening with the
> fact that python is a shared, not a static library?
>
>
> Backtrace (my own):
> 0x40280424 in PyDict_GetItemString () from
> /usr/lib/libpython2.2.so.0.0
> (gdb) bt
> #0 0x40280424 in PyDict_GetItemString () from
> /usr/lib/libpython2.2.so.0.0
> #1 0x4022e1a6 in get_interpreter_data () from
> /usr/lib/apache/1.3/mod_python.so
> #2 0x4022f0f4 in make_obcallback () from
> /usr/lib/apache/1.3/mod_python.so
> #3 0x402306f0 in python_finalize () from
> /usr/lib/apache/1.3/mod_python.so
> #4 0x08053a84 in ap_invoke_handler ()
> #5 0x0806338c in ap_some_auth_required ()
> #6 0x080633e8 in ap_process_request ()
> #7 0x0805cbcb in ap_child_terminate ()
> #8 0x0805cd5c in ap_child_terminate ()
> #9 0x0805ce79 in ap_child_terminate ()
> #10 0x0805d355 in ap_child_terminate ()
> #11 0x0805da5d in main ()
> #12 0x400ed0bf in __libc_start_main () from /lib/libc.so.6
>
> >From the bug logs:
> (gdb) bt
> #0 0x40438989 in PyDict_GetItem () from /usr/lib/libpython2.1.so.0.0
> #1 0x4043a051 in PyDict_GetItemString () from
> /usr/lib/libpython2.1.so.0.0
> #2 0x403bb1a6 in get_interpreter_data (name=3D0x80d9a0c
> "jt5-223b.tky.hut.=
> fi",
> srv=3D0x808898c) at mod_python.c:117
> #3 0x403bc0f4 in python_handler (req=3D0x813055c,
> handler=3D0x403c1b4b "PythonHandler") at mod_python.c:633
> #4 0x403bd6d0 in PythonHandler (req=3D0x813055c) at mod_python.c:1438
> #5 0x08053a44 in ap_invoke_handler ()
>
> #2 0x403bb1a6 in get_interpreter_data (name=3D0x80d9a0c
> "jt5-223b.tky.hut.=
> fi",
> srv=3D0x808898c) at mod_python.c:117
> 117 p =3D PyDict_GetItemString(interpreters, (char *)name);
> (gdb) p interpreters
> $1 =3D (PyObject *) 0x0
>
> Any ideas?
>
> Thanks,
> Peter
> peterh@debian.org
>
> --
> peter@hawkins.emu.id.au
> GPG key fingerprint:
> C746 38A9 D3E4 A171 FB6A 56D4 5E30 DFCC BE11 F437
>