php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #5517 Apache segmentation fault with unixODBC
Submitted: 2000-07-11 15:32 UTC Modified: 2000-08-23 09:10 UTC
From: m dot brooks at ukonline dot co dot uk Assigned:
Status: Closed Package: Dynamic loading
PHP Version: 4.0 Latest CVS (11/07/2000) OS: Linux - RedHat 6.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
5 + 11 = ?
Subscribe to this entry?

 
 [2000-07-11 15:32 UTC] m dot brooks at ukonline dot co dot uk
I have RedHat 6.1 Linux, Apache 1.3.12-2 RPM from RedHat, PHP 4.0.1pl2 tarball, unixODBC 1.8.8-1 RPM (Murray Todd's RPM build from the GrapeApe site grapeape.codingpages.com/odbc.xml).

I used the following config options:

./configure --with-unixODBC=/usr --with-apxs --without-mysql

Note the "/usr" for the unixODBC root, rather than the default of "/usr/local". kpackage shows the unixODBC libs to be placed in "/usr/lib", so I am inferring from this that the base install dir is "/usr". The make and make install appear to run successfully, with the exception of the updating of the httpd.conf file. This erroneously declares mod_php4 as being "usr/lib/apache/libphp4.so", rather than "modules/libphp4.so", so I have to manually edit that.

When I start Apache, it immediately falls over with nothing reported in error_log. An httpd -X reports a Segmentation fault. In neither case is a core dumped. Running from within gdb I get the following:

[root@localhost sbin]# gdb ./httpd
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
(gdb) run -X
Starting program: /usr/sbin/./httpd -X
Cannot access memory at address 0x403d4874.
(gdb) bt
#0  0x4000a6d1 in _dl_debug_state () at dl-debug.c:56
#1  0x4017c4e6 in _dl_close (map=0x80a69d8) at dl-close.c:195
#2  0x4009d0c0 in dlclose_doit (handle=0x80a69d8) at dlclose.c:26
#3  0x4000a3eb in _dl_catch_error (errstring=0x4009ed00, operate=0x4009d0a8 <dlclose_doit>, args=0x80a69d8) at dl-error.c:141
#4  0x4009d549 in _dlerror_run (operate=0x4009d0a8 <dlclose_doit>, args=0x80a69d8) at dlerror.c:125
#5  0x4009d08e in dlclose (handle=0x80a69d8) at dlclose.c:32
#6  0x806748c in ap_os_dso_unload ()
#7  0x804f9a0 in ap_get_server_built ()
#8  0x8051068 in ap_run_cleanup ()
#9  0x804fe59 in ap_clear_pool ()
#10 0x805bf76 in ap_child_terminate ()
#11 0x805c65f in main ()
#12 0x400b71eb in __libc_start_main (main=0x805c3e0 <main>, argc=2, argv=0xbffffd04, init=0x804f014 <_init>, fini=0x807b99c <_fini>,
    rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffcfc) at ../sysdeps/generic/libc-start.c:90
(gdb)

Note that if I configure PHP without the unixODBC option, everything works fine.

One possibility that comes to mind is the php.ini file. The make install does not create one for me, and this certainly does not prevent PHP itself from operating. However, are there any configuration options that must be set up for unixODBC to work? In the absence of any mention of specific unixODBC options in the documentation, I have tried using the unified ODBC options, but to no avail.

Regards,
Michael Brooks (mailto:m.brooks@ukonline.co.uk)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-07-27 22:08 UTC] zak@php.net
Please verify that it?s still happening using the latest version from CVS or snaps.php.net.
 [2000-07-28 09:28 UTC] m dot brooks at ukonline dot co dot uk
Sorry, but I've done a workaround in the form of my own portable PHP database communication class. Consequently I am no longer dependent upon ODBC, and I neither wish to risk my development environment by rebuilding PHP with the ODBC option, or to put in the time that would be required to keep chasing this bug. If you guys reckon the latest version of PHP fixes this, that sounds fine by me and I'm happy for you to close this bug.

Regards,
Michael Brooks
 [2000-07-28 11:32 UTC] waldschrott@php.net
what to do with this? suspend or close?
 [2000-07-28 11:52 UTC] kara@php.net
This is not really ODBC related - from the backtrace and due to the fact that apache doesn't log an error, it's a dso issue (conflicts between unixODBC rpm and apache rpm?)
Compiling Apache, unixODBC and PHP4 from source would probably help.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 13:01:30 2024 UTC