File: issues-with-expat-library.rst

package info (click to toggle)
mod-wsgi 5.0.2-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 2,824 kB
  • sloc: ansic: 15,512; python: 3,697; makefile: 219; sh: 107
file content (225 lines) | stat: -rw-r--r-- 10,784 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
=========================
Issues With Expat Library
=========================

This article describes problems caused due to mismatches in the version of
the "expat" library embedded into Python and that linked into Apache. Where
incompatible versions are used, Apache can crash as soon as any Python code
module imports the "pyexpat" module.

Note that this only applies to Python versions prior to Python 2.5. From
Python 2.5 onwards, the copy of the "expat" library bundled in with Python
is name space prefixed, thereby avoid name clashes with an "expat" library
which has previously been loaded.

The Dreaded Segmentation Fault
------------------------------

When moving beyond creating simple WSGI applications to more complicated
tasks, one can unexpectedly be confronted with Apache crashing. This
generally manifests in no response being returned to the browser when a
request is made. Upon further investigation of the Apache error log file, a
message similar to the following message is found::

    [notice] child pid 3238 exit signal Segmentation fault (11)

The change which causes this is the explicit addition of code to import the
Python module "pyexpat", or the importing of any Python module which
indirectly makes use of the "pyexpat" module. Examples of other modules
which make use of the "pyexpat" module are "xmlrpclib" and modules from the
"PyXML" package. Nearly always, any module which in some way performs
processing of XML data will be affected as most such modules rely on using
the "pyexpat" module in some way.

Verifying Expat Is The Problem
------------------------------

To verify that the "pyexpat" module is the trigger for the problem,
construct a simple WSGI application script file containing::

    def application(environ, start_response):
        status = '200 OK'
        output = 'without expat\n' 

        response_headers = [('Content-type', 'text/plain'), 
                            ('Content-Length', str(len(output)))]
        start_response(status, response_headers)

        return [output]

Verify that this handler works and the browser receives the response
"without pyepxat". Now modify the handler such that the "pyexpat" module is
being imported. Also change the response so that it is clear that the
modified handler is being used::

    import pyexpat

    def application(environ, start_response):
        status = '200 OK'
        output = 'with expat\n' 

        response_headers = [('Content-type', 'text/plain'), 
                            ('Content-Length', str(len(output)))]
        start_response(status, response_headers)

        return [output]

Presuming that script reloading is enabled, if now upon a request being
received by the WSGI application a succesful response of "with pyexpat" is
received by the browser, it would generally indicate that the "pyexpat"
module is not the problem after all. If however no response is received and
the Apache error log records a "Segmentation fault" then the "pyexpat"
module is the trigger.

Mismatch In Versions Of Expat
-----------------------------

Segmentation faults can occur with any application where different
components of the application were compiled against different versions of a
common library such as the "expat" library. The actual cause of the problem
is generally a change in the API of the library, such as changed function
prototypes, changed data types, or changes in structure layouts. In the
case where mod_wsgi is being used, the different components are Apache
and the "pyexpat" module from Python.

Normally when different components of an application are built, they would
be built against the same version of the library and such problems would
not occur. In the case of the "pyexpat" module however, it is compiled
against a distinct version of the "expat" library which is then embedded
within the "pyexpat" module. At the same time, Apache will be built against
the version of the "expat" library included with the operating system, or
if not a standard part of the operating system, a version which is supplied
with Apache.

Thus if the version of the "expat" library embedded into the "pyexpat"
module is different to that which Apache was compiled against, the
potential for this problem will exist. Note though that there may not
always be a problem. Whether there is or not will ultimately depend on what
changes were made in the "expat" library between the releases of the
different versions used. It is also possible how each library version was
compiled could be a factor.

Expat Version Used By Apache
----------------------------

To determine the version of the the "expat" library which is used by
Apache, on Linux the "ldd" command can be used. Other operating systems
also provide this program or will generally have some form of equivalent
program. For example, on Mac OS X the command which is run is "otool -L".

The purpose of these programs is to generate a list of all shared libraries
that an application is linked against. To determine where the "expat"
library being used by Apache is located, it is necessary to run the "ldd"
program on the "httpd" program. On a Linux system, the "httpd" program is
normally located in "/usr/sbin". Because we are only interested in the
"expat" library, we can ignore anything but the reference to that library::

    [grahamd@dscpl grahamd]$ ldd /usr/sbin/httpd | grep expat
            libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7e8c000)

From this output it can be seen that the "httpd" program appears to be
using "/usr/lib/libexpat.so.0". Although some operating systems embed in
the name of the shared library versioning information, it does not
generally indicate the true version of the code base which made up the
library. To obtain this, it is necessary to extract the version information
out of the library. For the "expat" library this can be determined by
searching within the strings contained in the library for a version string
starting with ``expat_``::

    [grahamd@dscpl grahamd]$ strings /usr/lib/libexpat.so.0 | grep expat_
    expat_1.95.8

The version of the "expat" library would therefore appear to be "1.95.8".
Unfortunately though, many operating systems allow the library search path
to be overridden at the point that a program is run using an environment
variable such as "LD_LIBRARY_PATH" and it is quite possible that when
Apache is run, the context in which it is run could result in it finding
the "expat" library in a different location.

To be absolutely sure, it is necessary to determine which "expat" library
the running copy of Apache used. On Linux and many other operating systems,
this can be determined using the "lsof" command. If this program doesn't
exist, an alternate program which may be available is "ofiles". Either of
these should be run against one of the active Apache processes. If Apache
was originally started as root, the command will also need to be run as
root::

    [grahamd@dscpl grahamd]$ ps aux | grep http | head -3
    root      3625  0.0  0.6 31068 12836 ?       SN   Sep25   0:08 /usr/sbin/httpd
    apache   24814  0.0  0.7 34196 15604 ?       SN   04:11   0:00 /usr/sbin/httpd
    apache   24815  0.0  0.7 33924 15916 ?       SN   04:11   0:00 /usr/sbin/httpd

    [grahamd@dscpl grahamd]$ sudo /usr/sbin/lsof -p 3625 | grep expat
    httpd   3625 root  mem    REG     253,0   123552    6409040
    /usr/lib/libexpat.so.0.5.0

    [grahamd@dscpl grahamd]$ strings /usr/lib/libexpat.so.0.5.0 | grep expat_
    expat_1.95.8

Expat Version Used By Python
----------------------------

To determine the version of the "expat" library which is embedded in the
Python "pyexpat" module, the module should be imported and the version
information extracted from the module. This can be done by executing
"python" on the command line and entering the necessary code directly::

    [grahamd@dscpl grahamd]$ python
    Python 2.3.3 (#1, May  7 2004, 10:31:40) 
    [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import pyexpat 
    >>> pyexpat.version_info
    (1, 95, 7)

Combining Python And Apache
---------------------------

When mod_wsgi is used from within Apache, although there is a version of
the "expat" library embedded in the "pyexpat" module, it will effectively
be ignored. This is because Apache has already loaded into memory at
startup the version of the "expat" library which it is linked against. That
this occurs can be seen by using the ability of Linux to forcibly preload a
shared library into a program when run, even though that program wasn't
linked against the library orginally. This is achieved using the
"LD_PRELOAD" environment variable::

    [grahamd@dscpl grahamd]$ LD_PRELOAD=/usr/lib/libexpat.so.0.5.0 python
    Python 2.3.3 (#1, May  7 2004, 10:31:40) 
    [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import pyexpat
    >>> pyexpat.version_info
    (1, 95, 8)

As can be seen, although the "pyexpat" module for this version of Python
embedded version 1.95.7 of the "expat" library, when the same version of
the "expat" library as was being used by Apache is forcibly loaded into the
program at startup, the version information obtained from the "pyexpat"
module now shows that version 1.95.8 of the "expat" library is being used.

Luckily in this case, the patch level difference between the two versions
of the "expat" library as used by Python and Apache doesn't cause a
problem. If however the two versions of the "expat" library were
incompatible, one would expect to see the "python" program crash with a
segmentation fault at this point. This therefore can be used as an
alternate way of verifying that it is the "pyexpat" module and more
specifically the version of the "expat" library used, that is causing the
problem.

Updating System Expat Version
-----------------------------

Because the version of the "expat" library embedded within the "pyexpat"
module is shipped as source code within the Python distribution, it can be
hard to replace it. The preferred approach to resolving the mismatch is
therefore to replace/update the version of the "expat" library that is used
by Apache.

Generally the problem occurs where that used by Apache is older than that
which is being used by Python. In that case, the version of the "expat"
library used by Apache should be updated to be the same version as that
embedded within the "pyexpat" module. By using the same version, one would
expect any problems to disappear. If problems still persist, it is possible
that Apache may also need to be recompiled against the same version of the
"expat" library as used in Python.