Hello,

I've run into a problem trying to get php 3.0.7+ working with Oracle 8
support as an Apache module on a Digital Unix system, and I'm afraid I'm
not having much luck.  I was wondering if anyone else out there is using
php in a similar configuration, and would care to shed some light on what
I might be doing wrong.  I've tried php versions 3.0.7, .8, .9, .10, .11
and the results are the same for all three.

We *have* successfully been using apache 1.3.1 + php 3.0.7 and Oracle 7.3.?
on the same box for quite some time.  We recently upgraded to Oracle 8 on
our production servers, and this web server was also upgraded to use Oracle 8
on the client side.  At that time, the php scripts that call Oracle functions
quit working, so I'm trying to get php built against the updated Oracle 8.0.5
libraries.  Since I needed to update php anyway, I thought I would also try
getting updated to Apache 1.3.6 at the same time.  I hate making so many
changes at once, but since php is intimately dependendent on Apache anyway
it seems that they should be done at the same time.

This is pretty lengthy, because I wanted to make sure to provide all the
information that I thought might make a difference.  If I've somehow left
something out, please let me know and I would be happy to provide additional
info.

The specifics:

System: dual processor 5/533 AS 4000, Digital Unix 4.0d + most of
patch set #3.
C compiler: Compaq's C compiler, "DEC C V5.6-079"

Apache details:
Version: 1.3.6
CFLAGS: -std -g -readonly_strings -portable
(note: of course I first tried with various types of optimization, but the
failure happens even with just debugging, as shown above)

configured as:

        ./configure --prefix=/local/apache-1.3.6 \
                --exec-prefix=/local/apache-1.3.6 \
            --disable-rule=WANTHSREGEX \
                --with-layout=GNU \
                --enable-shared=max \
                --enable-module=log_agent \
                --enable-module=log_referer \
                --enable-module=status \
                --enable-module=auth_db \
                --enable-module=auth_dbm \
                --enable-module=so

I installed apache in /local/apache-1.3.6, and I modified
/local/apache-1.3.6/sbin/apxs, because of a bug in that script that causes
`ld' to be passed

        -expect_unresolved *

instead of

        -expect_unresolved \*

when building loadable modules.

I then copied our apache config files from our 1.3.1 production apache tree
into /local/apache-1.3.6/etc, so that the 1.3.6 test server is using the
exact same config as the 1.3.1 production server.


I then built php, using:

PHP version: 3.0.7 - 3.0.11 (results are the same for each)
IMAP version: 4.2
Oracle version: 8.0.5

relevant build info:

        CFLAGS="-std1 -g"
        CFLAGS="$CFLAGS -readonly_strings -portable"
        export CC CFLAGS
        LIBS="$LIBS -lsecurity"
        export LIBS
        CPPFLAGS="$CPPFLAGS -I%{ORACLE_HOME}/rdbms/demo"
        CFLAGS="$CFLAGS -I%{ORACLE_HOME}/rdbms/demo"
        export CPPFLAGS CFLAGS

where ORACLE_HOME is earlier defined to be:

        /usr/users/admin/oracle/product/8.0.5

(I'm using RPM to build local software, hence the support for variables defined
earlier in the spec file, like %{ORACLE_HOME}).

Note 1: I've found that if I try build libphp3.so without first adding
`-lsecurity' to LIBS, when I try start httpd after libphp3.so has been
installed in /local/apache-1.3.6/libexec, I get a complaint from the loader
that setluid() could not be found.  setluid() is being dragged in because of
the IMAP support -- it's used for the Login/Audit uid stuff in
imap-4.2/c-client code.  This means that on Digital Unix, when building with
IMAP support one is also required to link in libsecurity, to get setluid().
setluid() is needed independent of whether you're running base or enhanced/C2
security on the machine.  This would be the same on any other OS that has
the SecureWare security stuff with the audit ID.

Note 2: Before running the following configure line, I first patch/edit the
configure script, to remove the `-Wl,-rpath' entries that would be used to
build in RPATHs into the libphp3.so.  I'm not against using them (in fact, I
applaud that the php developers are trying to do the right thing in the
configure script!), but in my case it's not necessary and is actually more
desireable to not have the RPATHs.  The only two "add-on" libraries I'm trying
to link with are the IMAP 4.2 library (which is built static and doesn't need
any rpath stuff) and the Oracle 8.0.5 library.  Although I would normally never
do this, for the case of Oracle I've just copied the libclntsh.so.1.0 library
from the Oracle lib directory into /usr/shlib, where it will always be found
by the loader.  Hence, no need for RPATHs.  This allows me to build a
libphp3.so via RPM, and install it on any box that has Oracle 8, even if
ORA_HOME is different from the location on the build box.

Next I configure php, like this:

        ./configure  --prefix=/local/apache-1.3.6 \
                --exec-prefix=/local/apache-1.3.6 \
                --with-apxs=/local/apache-1.3.6/sbin/apxs \
                --with-imap=imap-4.2/c-client \
                --with-oracle=/usr/users/admin/oracle/product/8.0.5 \
                --with-system-regex


php compiles with a few warnings, and the end result is that ld is invoked and
creates libphp3.so, like this:

ld -shared -expect_unresolved \*  -o libphp3.so mod_php3.o pcrelib/libpcre.a -lm -
lsecurity -lresolv libmodphp3-so.a -Lpcrelib -lpcre -L/usr/local/lib -L/usr/users/
admin/oracle/product/8.0.5/lib -Limap-4.2/c-client/lib -lclntsh -lpsa -lcore 4 -ln
lsrtl3 -lclntsh -lexc -lmld -lrt -laio -lm -ldb -lc-client


If I install this in my /local/apache-1.3.6/libexec directory, where my 1.3.6

test server is, and then start httpd, I've found that the httpd will not
sucessfully start.  I get absolutely nothing in the apache logs, but by using
the first httpd forks (in preparation for going into daemon mode), its only
child gets a SEGV after a call to munmap().  This is so early in the startup
that it explains why nothing is logged, but it also has made the problem
extremely hard to debug.

I can tell you that I've tried:

1) various combinations of CFLAGS, including compiling with (and without)
optimization and with and without debugging, and the results are always the
same.

2) thinking that it may be some weird problem caused by using the
--with-system-regex for php but using the Apache regex stuff, I've tried
compiling apache with (and without) the

        --disable-rule=HSREGEX

and the results are the same.

3) thinking that it may be because I'm using the 1.3.1 apache config files
(srm.conf, access.conf, httpd.conf) with the 1.3.6 apache server, I
started with a fresh 1.3.6 httpd.conf file and merged all our local
config settings into that file.  Results are the same -- httpd crashes.

4) If I build php 3.0.[7,8,9,10,11] *without* Oracle 8 support, httpd does *not*
crash.  It will go into daemon mode, and create StartServers # of children,
and things appear to work as expected.  Unfortuntely, this doesn't get me
any closer to having Oracle 8 support.

5) After reading the "Bugs Dos and Don'ts" on the php bug site, I tried
running httpd under a debugger in non-daemon mode (via the -X flag to httpd --
thanks for pointing that out!).  I can get the debugger to catch the sigsegv,
but unfortunately that hasn't done me much good so far.  GDB (4.17 and 4.18)
on Digital Unix often fails to generate a full stack backtrace, giving a
"hit-heuristic-fencepost" warning that seems to be indicative of some problem
in gdb, and dbx doesn't seem to do any better.

*However*, I've just now thought to try DEC's successor to dbx, `ladebug'.
I've found it pretty clunky to use in the past, but this time it came up with
something!  Here's the stack trace:

(ladebug) load /local/apache-1.3.6/sbin/httpd
Reading symbolic information ...done
(ladebug) run -X
Thread received signal SEGV
pc address 0x3ff82035ca0 is invalid; substituting RA
stopped at [__get_libc_context 0x3ff8013a568]
(ladebug) where
>0  0x3ff8013a568 in __get_libc_context(0xfffffffffffffff0, 0x1200072a8,
0x60aaec4, 0x2, 0x3ff801357e8, 0x0) DebugInformationStrippedFromFile602
#1  0x3ff801357e4 in __dlclose(0x3ff801357e8, 0x0, 0x12003b330, 0x14000c470,
0x0, 0x0) DebugInformationStrippedFromFile648
#2  0x12003b32c in ap_os_dso_unload(handle=0x15) os.c:123
#3  0x1200119ac in unload_module(modi=0x14000c470) mod_so.c:181
#4  0x12001fd28 in run_cleanups(c=0x140018e28) alloc.c:1650
#5  0x12001df40 in ap_clear_pool(a=0x14000c018) alloc.c:475
#6  0x120016b60 in standalone_main(argc=2, argv=0x11ffff4a8) http_main.c:4251
#7  0x1200176fc in main(argc=2, argv=0x11ffff4a8) http_main.c:4591





I don't know if this will help, but here's the last few lines of the output
from running:

        trace -f -P /local/apache-1.3.6/sbin/httpd -X


[earlier stuff elided]


[30791]: read (4, 0x400822e8, 8192) = 0
[30791]: close (4) = 0
[30791]: open ("/local/apache-1.3.6/var/log/access_log", O_WRONLY|O_CREAT|O_APPEND
, 644) = 4
[30791]: fcntl (4, F_DUPFD, 15) = 16
[30791]: syscall (4, 4, 15, 0, 0, 10) = 0
[30791]: getpid () = 30791
[30791]: gettimeofday (0x11ffff368, 0x0) = 0, [ {928906611, 922848}, {} ]
[30791]: syscall (16, 16, 4831970588, 0, 0, 10) = 0
[30791]: close (15) = 0
[30791]: munmap (0x30000000000, 1097728) = 0
[30791]: munmap (0x300400b0000, 278528) = 0
[30791]: munmap (0x300400f4000, 78080) = 0
[30791]: munmap (0x3ff80830000, 278528) = 0
[30791]: munmap (0x3ffc0280000, 24576) = 0
[30791]: munmap (0x3ffc0286000, 731776) = 0
[30791]: munmap (0x30000800000, 5177344) = 0
[30791]: munmap (0x30040ca0000, 229376) = 0
[30791]: munmap (0x30040cd8000, 84080) = 0
[30791]: madvise (0x3ffc0012000, 49152, 6) = 0
[30791]: munmap (0x3ff807b0000, 24576) = 0
[30791]: munmap (0x3ffc0210000, 8192) = 0
[30791]: munmap (0x3ff80cf0000, 49152) = 0
[30791]: munmap (0x3ffc0510000, 16384) = 0
[30791]: munmap (0x3ff81000000, 32768) = 0
[30791]: munmap (0x3ffc05d0000, 8192) = 0
[30791]: munmap (0x3ff80810000, 24576) = 0
[30791]: munmap (0x3ffc0260000, 8192) = 0
[30791]: munmap (0x3ff80550000, 245760) = 0
[30791]: munmap (0x3ffc0180000, 65536) = 0
[30791]: munmap (0x3ffc0190000, 432) = 0
[30791]: munmap (0x3ff80530000, 65536) = 0
[30791]: munmap (0x3ffc0170000, 16384) = 0
[30791]: SIGNAL [11 SIGSEGV]
nxm upcall: can't grow stack, pid 30791, proc httpd
[30791]: EXIT [signal=11]



As you can see, it's clearly apache that's core dumping, but based on the
fact that it *doesn't* happen if I don't compile Oracle support into
libphp3.so and it doesn't happen if I just don't load libphp3.so at all,
it seems likely that the Apache people would believe it's a problem in PHP.

Thanks for your time,

Darren Seifert