Bug #16589 Updated: php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error

[misiek]

 ID:   16589
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
-Bug Type: Zlib Related
+Bug Type: Reproducible crash
 Operating System: PLD Linux
 PHP Version:  4.2.0RC3
 New Comment:

Doesn't change anything (category changed). It happens if _any_ of my
php modules is loaded in php.ini...

My php is split in that way, see: ftp://ftp.pld.org.pl/test/i686/php*
(ps. this is apache 1.3 version but I'm using this recompiled with
apache 2.0.35).


Previous Comments:


[2002-04-13 23:26:58] [EMAIL PROTECTED]

What if you remove the zlib.so from your php.ini?




[2002-04-13 12:50:20] [EMAIL PROTECTED]

First update php.ini to reflect the correct extension dir. You're using
a lib compiled with debug=1 and a php version without.

The extension dir, then changes.



[2002-04-13 11:21:18] [EMAIL PROTECTED]

Fix version.



[2002-04-13 11:20:41] [EMAIL PROTECTED]

php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error:

#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) bt
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
#1  0x00839856 in php_log_err (
log_message=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"..., tsrm_ls=0x1775ff0) at
main.c:324
#2  0x00839d57 in php_error_cb (type=32, error_filename=0x8e8f2b
"Unknown", error_lineno=0, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n", 
args=0xb758 "wâ|") at main.c:459
#3  0x0082c917 in zend_error (type=32, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n") at zend.c:682
#4  0x0088cd51 in php_dl (file=0x1d46ff0, type=1,
return_value=0xb7c0, tsrm_ls=0x1775ff0) at dl.c:202
#5  0x0083f5c3 in php_load_function_extension_cb (arg=0x1d46ff0,
tsrm_ls=0x1775ff0) at php_ini.c:188
#6  0x008244cd in zend_llist_apply (l=0x915f3c, func=0x83f58a
, tsrm_ls=0x1775ff0)
at zend_llist.c:186
#7  0x0083faa4 in php_ini_delayed_modules_startup (tsrm_ls=0x1775ff0)
at php_ini.c:313
#8  0x0083ba4b in php_module_startup (sf=0x77a020) at main.c:1001
#9  0x00778ca3 in php_apache_server_startup (pconf=0x4d4010,
plog=0x513010, ptemp=0x516010, s=0x4fe118)
at sapi_apache2.c:435
#10 0x080681e5 in ap_run_post_config (pconf=0x4d4010, plog=0x513010,
ptemp=0x516010, s=0x4fe118) at config.c:130
#11 0x0806e545 in main (argc=2, argv=0xb9e4) at main.c:569
#12 0x003c0418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) print ctx
$8 = (struct php_struct *) 0x0
(gdb) 





-- 
Edit this bug report at http://bugs.php.net/?id=16589&edit=1

Bug #16594: mktime() when passed a 0 for the day of the month to get the last day is broken

[lchang]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.5
PHP version:  4.1.2
PHP Bug Type: Date/time related
Bug description:  mktime() when passed a 0 for the day of the month to get the last 
day is broken

When you use mktime(0,0,0,,,) and specify 0 as the day to
get the last day of the month, the last day of the month returned is off.
It seems that the months are all off by 1 after January. So with mktime(),
for February, the last day is the 31st, for March it is the 28th, for
April it is the 31st, etc. And instead February should be the 28th, March
the 31st, and April the 30th, etc...

';
  //Last day should be 31, but is 28
  $day = getdate( mktime(0,0,0,3,0,2002) );
  print 'The last day for March is: ' . $day[mday];
  
?>
-- 
Edit bug report at http://bugs.php.net/?id=16594&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16594&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16594&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16594&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16594&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16594&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16594&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16594&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16594&r=submittedtwice

Bug #16593: x^y gives unusual results

[paul]

From: [EMAIL PROTECTED]
Operating system: Win XP
PHP version:  4.1.2
PHP Bug Type: *Math Functions
Bug description:  x^y gives unusual results

x^y should always yield a positive number, however when doing -2^2 and
(-2)^2, I get a result of -4!

Surely this aint right?
-- 
Edit bug report at http://bugs.php.net/?id=16593&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16593&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16593&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16593&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16593&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16593&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16593&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16593&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16593&r=submittedtwice

Bug #15310 Updated: when use object method call session register doesn't work

[php-bugs]

 ID:   15310
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Session related
 Operating System: linux
 PHP Version:  4.1.1
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-01 02:49:31] [EMAIL PROTECTED]

I mean value of $_SESSION['time'] lost at refresh.
When I comment line $test->t() script works correctly:

Array
(
[time] => 1012549372
)

--new _SESSION:--

Array
(
[time] => 1012549373
)

When I remove comment the output is like this (don't forget begin new
session):

Array
(
)

--new _SESSION:--

Array
(
[time] => 1012549537
)



[2002-02-01 02:22:49] [EMAIL PROTECTED]

What do you mean "it has not given result".

If you mean $time does not have value, it's normal.
if $_SESSION['time'] does not have value something wrong.
If you mean you don't see $test->$mT['TEST']['_SESSION_']['time'] does
not have value, it's your bug.

Please try to be more specific.





[2002-01-31 06:06:48] [EMAIL PROTECTED]

I have removed session_register() call and began new session,  but it
has not given result.



[2002-01-31 05:31:45] [EMAIL PROTECTED]

As I changed session manual recently,
NEVER use $_SESSION(or $HTTP_SESSION_VARS) AND
session_register/is_registered/unregister() functions.
(It's not only for 4.1.x but also for 4.0.x)

I warned it already. 

tracked vars and globals are handled inconsistent manner in session
module. 
I really would like to get rid of global var support from session module
for PHP5



[2002-01-31 04:50:23] [EMAIL PROTECTED]

Following code the shows strange bag.
When function t() called as object method, variable 'time' is not kept
in session.
Register_globals is On.

mT['TEST'] = $GLOB;
}
}
$test = new Test;
$test->t(); // comment this line and script will work right
?>







-- 
Edit this bug report at http://bugs.php.net/?id=15310&edit=1

Bug #16584 Updated: GD compile failure

[sniper]

 ID:   16584
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: FreeBSD 4.3-STABLE
 PHP Version:  4.2.0RC3
 New Comment:

The CLI version of PHP is experimental in PHP 4.2.0.
The RC3 was supposed to have it disabled by default,
but there was a bug in the configure.
Fixed in CVS and will be in next RC and the release.



Previous Comments:


[2002-04-13 06:33:39] [EMAIL PROTECTED]

Edited to correct version (4.2.0RC3)



[2002-04-13 06:33:03] [EMAIL PROTECTED]

Compile with GD 2.0.1 doesn't work anymore (used to work fine with
earlier versions of PHP with the exact same parameters). Configure :
./configure \
--prefix=/usr/home//local \
--enable-bcmath \
--with-zlib \
--with-png-dir=/usr/local \
--with-jpeg-dir=/usr/local \
--with-tiff-dir=/usr/home//local \
--with-t1lib=/usr/home//local \
--with-freetype-dir=/usr/home//local \
--enable-gd-native-ttf \
--with-gd=/usr/home//local \
--enable-exif \
--with-mysql=/usr/local \
--with-ming=/usr/home//local \
--disable-pear \
--with-config-file-path=/usr/home//local/etc \
--enable-debug=no \
--enable-force-cgi-redirect=yes \
--with-openssl=/usr/local/ssl \
--with-curl=/usr/home//src/curl-7.9 \
--with-dom=/usr/home//local

And the compile error message :
./.libs/libphp4cli.a(gd.o): In function `zif_imagecreatetruecolor':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0xd9e): undefined
reference to `gdImageCreateTrueColor'
./.libs/libphp4cli.a(gd.o): In function `zif_imagetruecolortopalette':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0xf2b): undefined
reference to `gdImageTrueColorToPalette'
./.libs/libphp4cli.a(gd.o): In function `zif_imagesetthickness':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x1032): undefined
reference to `gdImageSetThickness'
./.libs/libphp4cli.a(gd.o): In function `zif_imagefilledellipse':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x136a): undefined
reference to `gdImageFilledEllipse'
./.libs/libphp4cli.a(gd.o): In function `zif_imagefilledarc':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x1836): undefined
reference to `gdImageFilledArc'
./.libs/libphp4cli.a(gd.o): In function `zif_imagealphablending':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x193a): undefined
reference to `gdImageAlphaBlending'
./.libs/libphp4cli.a(gd.o): In function `zif_imagecolorresolvealpha':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x1bd1): undefined
reference to `gdImageColorResolveAlpha'
./.libs/libphp4cli.a(gd.o): In function `zif_imagecolorclosestalpha':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x1e61): undefined
reference to `gdImageColorClosestAlpha'
./.libs/libphp4cli.a(gd.o): In function `zif_imagecolorexactalpha':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x20f1): undefined
reference to `gdImageColorExactAlpha'
./.libs/libphp4cli.a(gd.o): In function `zif_imagecopyresampled':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c:882: undefined reference to
`gdImageCopyResampled'
./.libs/libphp4cli.a(gd.o): In function `php_imagettftext_common':
/usr/home//src/php-4_2_0RC3/ext/gd/gd.c(.text+0x8aa5): undefined
reference to `gdImageStringFT'
*** Error code 1

Stop in /usr/home//src/php-4_2_0RC3/sapi/cli.
*** Error code 1

Stop in /usr/home//src/php-4_2_0RC3/sapi/cli.
*** Error code 1

Stop in /usr/home//src/php-4_2_0RC3.





-- 
Edit this bug report at http://bugs.php.net/?id=16584&edit=1

Bug #16589 Updated: php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error

[sniper]

 ID:   16589
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Zlib Related
 Operating System: PLD Linux
 PHP Version:  4.2.0RC3
 New Comment:

What if you remove the zlib.so from your php.ini?



Previous Comments:


[2002-04-13 12:50:20] [EMAIL PROTECTED]

First update php.ini to reflect the correct extension dir. You're using
a lib compiled with debug=1 and a php version without.

The extension dir, then changes.



[2002-04-13 11:21:18] [EMAIL PROTECTED]

Fix version.



[2002-04-13 11:20:41] [EMAIL PROTECTED]

php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error:

#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) bt
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
#1  0x00839856 in php_log_err (
log_message=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"..., tsrm_ls=0x1775ff0) at
main.c:324
#2  0x00839d57 in php_error_cb (type=32, error_filename=0x8e8f2b
"Unknown", error_lineno=0, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n", 
args=0xb758 "wâ|") at main.c:459
#3  0x0082c917 in zend_error (type=32, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n") at zend.c:682
#4  0x0088cd51 in php_dl (file=0x1d46ff0, type=1,
return_value=0xb7c0, tsrm_ls=0x1775ff0) at dl.c:202
#5  0x0083f5c3 in php_load_function_extension_cb (arg=0x1d46ff0,
tsrm_ls=0x1775ff0) at php_ini.c:188
#6  0x008244cd in zend_llist_apply (l=0x915f3c, func=0x83f58a
, tsrm_ls=0x1775ff0)
at zend_llist.c:186
#7  0x0083faa4 in php_ini_delayed_modules_startup (tsrm_ls=0x1775ff0)
at php_ini.c:313
#8  0x0083ba4b in php_module_startup (sf=0x77a020) at main.c:1001
#9  0x00778ca3 in php_apache_server_startup (pconf=0x4d4010,
plog=0x513010, ptemp=0x516010, s=0x4fe118)
at sapi_apache2.c:435
#10 0x080681e5 in ap_run_post_config (pconf=0x4d4010, plog=0x513010,
ptemp=0x516010, s=0x4fe118) at config.c:130
#11 0x0806e545 in main (argc=2, argv=0xb9e4) at main.c:569
#12 0x003c0418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) print ctx
$8 = (struct php_struct *) 0x0
(gdb) 





-- 
Edit this bug report at http://bugs.php.net/?id=16589&edit=1

Bug #16519 Updated: makefile error

[sniper]

 ID:   16519
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: linux redhat 7.2
 PHP Version:  4.1.2
 New Comment:

I installed the same j2sdk you have, and configured with
this configure line:

# ./configure --with-java=/usr/java/j2sdk1.4.0/ 
# make 

and it worked just fine. (both latest CVS and RC3)

Please try with the same configure line I have (and clean sources)




Previous Comments:


[2002-04-13 18:04:08] [EMAIL PROTECTED]

Hi,
compiled php-4.2.0RC3 on my local linux box with the same errors.
configure runs well, but make creates the 
following output:
Making all in java
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/opt/src/php-4_2_0RC3/ext/java«make[3]: Wechsel in das 
Verzeichnis Verzeichnis »/opt/src/php-4_2_0RC3/ext/java«/bin/sh
/opt/src/php-4_2_0RC3/libtool --silent 
--mode=compile gcc -I. -I/opt/src/php-4_2_0RC3/ext/java
-I/opt/src/php-4_2_0RC3/main -I/opt/src/php-4_2_0RC3 
-I/opt/src/php-4_2_0RC3/Zend -I/opt/src/php-4_2_0RC3/ext/mysql/libmysql

-I/opt/src/php-4_2_0RC3/ext/xml/expat -I/usr/java/j2sdk1.4.0//include
-I/usr/java/j2sdk1.4.0//include/linux 
-I/opt/src/php-4_2_0RC3/TSRM -g -O2 -prefer-pic -DJNI_12 -D_REENTRANT 
'-DJAVALIB="/usr/java/j2sdk1.4.0//./jre/lib/i386/libjava.so"' -c java.c
&& touch java.slo
/opt/src/php-4_2_0RC3/build/shtool mkdir -p net/php
javac net/php/reflect.java
/usr/bin/jar cf php_java.jar net/php/*.class net/php/*.properties
net/php/*.class: no such file or directory
make[3]: *** [php_java.jar] Fehler 2
make[3]: Verlassen des Verzeichnisses Verzeichnis
»/opt/src/php-4_2_0RC3/ext/java«
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/opt/src/php-4_2_0RC3/ext/java«
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis
»/opt/src/php-4_2_0RC3/ext«
make: *** [all-recursive] Fehler 1
this is exactly the same as with php4.1.2. System is a standart
automatically
updated redhat7.2 system. Automatically means, using redhat up2date.
Kernel is .31 at the moment - system is newly installed, all I changed
was removing the php4.0.6 rpms, installing java from current sun rpms
and trying to compile java with the following script:
./configure--with-zlib-dir\
   --enable-pcntl \
   --sbindir=/opt/sbin \
   --bindir=/opt/bin \
   --exec-prefix=/opt \
   --libexecdir=/opt/libexec \
   --datadir=/opt/share \
   --libdir=/opt/lib \
   --program-suffix=4 \
   --with-gd=/usr \
   --enable-sigchild \
   --with-png-dir=/usr/local \
   --with-mysql \
   --enable-shmop\
   --with-gdbm\
   --with-java=/usr/java/j2sdk1.4.0/\
   --enable-ftp
Checking showed the same as before:
in ext/java is a subdirectory structure:
net/php/net/php
where it should only be
net/php
the additional directories are created by the makefile in ext/java, or
better by the line
javac net/php/reflect.java
which creates the reflect.class file to net/php/net/php/reflect.class
instead of net/php/reflect.class...
will try on snapshot version tomorrow;)
good night,
flim



[2002-04-12 18:18:46] [EMAIL PROTECTED]

I can not reproduce this with PHP 4.2.0RC3 or latest CVS.
Please try them: http://www.php.net/~derick/ (for the RC3)
http://snaps.php.net/ (snapshots)

--Jani




[2002-04-09 16:51:56] [EMAIL PROTECTED]

Hi,
line 25 of the makefile in ext/java causes a folder construction like
net/php/net/php and put the compiled class in that deepest folder. This
causes the compiler to stop as it cannot find the  file...and if you
move it manually it can't remove the folders;)
this should solve it though (unless you want to train your users;=))
pushd net/php
javac reflect.java
popd

regards,
flim




-- 
Edit this bug report at http://bugs.php.net/?id=16519&edit=1

Bug #16592 Updated: manuals

[mfischer]

 ID:   16592
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Unknown/Other Function
 Operating System: win
 PHP Version:  4.1.2
 New Comment:

That's correct. Bz2 is a compression format. There are also hints how
to handle this, please read carefully.

Bz2 will be removed hopefully in the near future.


Previous Comments:


[2002-04-13 21:10:33] [EMAIL PROTECTED]

Your download page of manuals doesn't work.  It adds .bz2 to the name
of the file and then the intended software e.g. Adobe can't read it.




-- 
Edit this bug report at http://bugs.php.net/?id=16592&edit=1

Bug #16592: manuals

[chvol]

From: [EMAIL PROTECTED]
Operating system: win
PHP version:  4.1.2
PHP Bug Type: Unknown/Other Function
Bug description:  manuals

Your download page of manuals doesn't work.  It adds .bz2 to the name of
the file and then the intended software e.g. Adobe can't read it.
-- 
Edit bug report at http://bugs.php.net/?id=16592&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16592&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16592&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16592&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16592&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16592&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16592&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16592&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16592&r=submittedtwice

Bug #14876 Updated: ImageTTFText produces strange Warning

[Jouser]

 ID:   14876
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

Does anyone know if the same person who compiled php_gd.dll also
compiled php_gd2.dll?

I think the problem might be that whoever compiled the php_gd2.dll that
ships with PHP forgot to compile FreeType library while compiling GD.
This is only a guess because I heard someone say that ImageTTFtext
works on unix machines which leads me to believe this is the problem. I
would test it myself but I don't know how to compile the file :-(


Previous Comments:


[2002-01-05 14:49:22] [EMAIL PROTECTED]

Hi.

I can't use ImageTTFText with PHP_GD2.DLL (on Windows 2000). 

The Following Code works on GD1 with 4.1.1 and also GD2 with 4.0.6
(both downloadable compilations) ...

$im = ImageCreate (300, 300);
$color = ImageColorAllocate ($im, 255,135,000);
$black = ImageColorAllocate ($im, 000,000,000);
$white = ImageColorAllocate ($im, 255,255,255);
ImageFill ($im, 0,0, $color);
ImageTTFText ($im, 9, 0, 10, 200, $white, "\WINNT\Fonts\verdana.ttf",
"Hello");

ImagePNG ($im);

And produces a Warning like this.

"Warning: & in f:\http\test\php\testat.php on line 9"

The five chars following the "Warning:" are different depending at
least on the give font-path (IMHO).

I tried varios combinations: Path seperation with "/" and "\", several
locations: Absolute paths, fonts beeing in the script directory. apache
directory, php directory, with and without leading drive-letter.

GD2 is the only extension included.

Win2KSP2(German)/Apache 1.3.22/PHP 4.1.1

+++adam




-- 
Edit this bug report at http://bugs.php.net/?id=14876&edit=1

Bug #15235 Updated: file("http://[...]") never times out

[shiflett]

 ID:   15235
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: HTTP related
 Operating System: RH Linux 7.2
 PHP Version:  4.1.1
 New Comment:

I'm not familiar with the code behind the file() function myself, but
would you mind trying this with a more recent version of PHP?

If the bug was fixed by someone else somewhere along the way, there's
no need to try and fix it again.

Thanks.


Previous Comments:


[2002-01-26 16:44:28] [EMAIL PROTECTED]

When using the file function on an http document that is down (for
example today 1/26 dailynews.yahoo.com was 
down)  I had a page to go and get the news from dailynews.yahoo.com. 
When dailynews.yahoo.com was down, the 
page never loaded, it hung.  I know I can use socket_set_timeout or
something like that, but this doesn't 
effect the file() function.





-- 
Edit this bug report at http://bugs.php.net/?id=15235&edit=1

Bug #16353 Updated: can upload other files but not zip or visio files

[shiflett]

 ID:   16353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: HTTP related
 Operating System: Irix 6.5
 PHP Version:  4.0.6
 New Comment:

If this problem persists, it would be very helpful if you could capture
(or have someone else capture) the underlying HTTP traffic this
transaction produces.

Feel free to email me personally if you would like help in this regard.


Previous Comments:


[2002-04-04 16:01:43] [EMAIL PROTECTED]

You're right about it being browser related.  Uploading zip and visio
files works with IE 6, but not with Netscape 6.2 or 4.7x and not with
IE 5.0.  I haven't tested IE 5.5.  Our admin will compile and install
the latest RC in the next few days.  I'll report back on how that
affected uploads of our problem files.



[2002-04-02 13:40:39] [EMAIL PROTECTED]

I think it's a problem with your browser, not with PHP. Anyway, can you
try the latest RC from www.php.net/~derick ?



[2002-03-29 16:28:08] [EMAIL PROTECTED]

I have file uploads working with images, Word and Excel files and text
files, but when I try  to upload zip or visio files I see this message:
"Unable to open 'none' for reading. No such file or directory..." It
captures the name and mime type (application/x-zip-compressed and
application/octet-stream, resp.) but $attachment is set to 'none' and
$attachment_size is 0.  

Here's the relevant part of the form:







Here's the relevant part of the script that handles it:

$strLength1 = strlen($attachment_name);

 if ($strLength1 > 0) {

  $suffix1 = substr($attachment_name,($strLength1 - 4),4);

  $upfile1 =
"/www/pub/changecontrol/files/".$latestRecord."-1".$suffix1; 
//$latestRecord is defined earlier
  if (!copy($attachment,$upfile1)) {

echo "Problem: Could not move file into directory.";

exit;

  }

}

Any workaround for this?
We're using Apache 1.3.18.




-- 
Edit this bug report at http://bugs.php.net/?id=16353&edit=1

Bug #16337 Updated: include() does not decode % correctly

[shiflett]

 ID:   16337
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: Unix based
 PHP Version:  4.1.0
 New Comment:

RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is
still adhered to is incorrect.

The username:password string is base-64 encoded for Basic
Authentication, which I'm going to assume you're using, since you
didn't mention what type of authentication the server demands for
access to http://www.example.org/. It is not URL encoded.

Now, as for your bug report, why in the world would the include
function *decode* the username:password string? The content coming back
from the server doesn't specify the username and password to be used;
that's what *you* sent.

See RFC 2617 for more information about both Basic and Digest
Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point
you there.

I think a better understanding of this might help you solve your
problem on your own. However, if this does not help, it should at least
allow you to better explain what the problem is, because your reports
have too many holes for me to understand what problem you are having,
whether a bug in PHP or not.


Previous Comments:


[2002-04-10 20:01:07] [EMAIL PROTECTED]

in case anyone wondered, the HTTP spec I am refering to, is at:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
(Section 11.1)
Since RFC 2616 doesn't specify user-pass strings, I assume this older
RFC still applies.



[2002-04-10 19:57:48] [EMAIL PROTECTED]

Correction: 
 PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all.  Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.



[2002-03-28 18:12:28] [EMAIL PROTECTED]

When include() is called with the following syntax:

include("http://username:[EMAIL PROTECTED]/";);

It is the duty of the include call to tokenize the username and
password, and to urldecode each of them.  Why?  Because things would
break if a username contained 'www.example.com/?var='  or say a
password contained an @.  So, it is the duty of the caller to urlencode
these tokens, and the duty of include (or a sub function) to unencode
it after parsing.  

However, it has been observed in PHP 4.1.x that '%' characters (or
their equivalent '%25') are not decoded properly.  Prior use of this
feature leads us to believe the 4.0.x series of PHP does not have this
problem.  

We run websites with hundreds of users.  We would appreciate a quick
response, because we would rather not force all users with '%'s in
their passwords to change them.  Thank you.




-- 
Edit this bug report at http://bugs.php.net/?id=16337&edit=1

Bug #16346 Updated: MSIE Cookies problem

[shiflett]

 ID:   16346
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: Linux 7.2
 PHP Version:  4.1.1
 New Comment:

Please explain what the bug is. Your submission makes no sense, and we
are often too busy to spend time trying to interpret every bug report.

Please be more clear.


Previous Comments:


[2002-03-29 11:05:07] [EMAIL PROTECTED]

I use string 
setcookie('some_c_name','user', $var);

PHP 4.4.1
$var| exp date 
IE 5.5
9600 -> Jan 01 2070 02:40:00
3600 -> Jan 01 2070 01:00:00
1-> Jan 01 2070 00:00:01
time()+(60 * 60 * 24 * 30) -> Cant see this cook

NC
9600 -> Jan 01 02:00:01 1970
3600 -> Jan 01 02:00:01 1970
1-> Jan 01 02:00:01 1970
time()+(60 * 60 * 24 * 30) -> Apr 28 17:42:00 2002

I am used the test (http://www.chipchapin.com/WebTools/cookietest.php)

PHP 4.1.1
Method 1: OK
Method 2: Fail
Method 3: Fail
Method 4: OK
Method 5: Fail
Method 6: OK
Method 7: Fail
Method 8: OK
Method 9: OK
Method 10: Fail
Method 11: Fail
Method 12: Fail
Method 13: Fail

PHP 4.0.6
Method 1: OK
Method 2: OK
Method 3: OK
Method 4: OK
Method 5: OK
Method 6: OK
Method 7: OK
Method 8: OK
Method 9: OK
Method 10: OK
Method 11: OK
Method 12: Fail
Method 13: OK




-- 
Edit this bug report at http://bugs.php.net/?id=16346&edit=1

Bug #16342 Updated: can not set cookie with domain specified

[shiflett]

 ID:   16342
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: cookies and domain
 PHP Version:  4.1.1
 New Comment:

Try this:

setcookie("test_cookie", "test$exp", $exp, "/", ".domain.com");

Also, don't forget that you can just write your own header with the
header() function. If, for some reason, there *is* a problem with
setcookie(), you can always just write your own to be sure.

If my above example doesn't fix the problem, please try to give me the
HTTP traffic, specifically the response. If you're unsure how to do
this, feel free to email me personally.

Hope that helps.

Chris


Previous Comments:


[2002-03-29 07:36:06] [EMAIL PROTECTED]

If I specify a domain, cookie is not set:

This works:
$exp = time()+120;
setcookie ("TestCookie", "TEST$exp",$exp);

This doesn't work:
$exp = time()+120;
setcookie ("TestCookie", "TEST$exp",$exp, "/", "www.domain.com");

Doesn't set a cookie at all. Any ideas?







-- 
Edit this bug report at http://bugs.php.net/?id=16342&edit=1

Bug #15639 Updated: detecting end of UDP packets

[wez]

 ID:   15639
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *Network Functions
 Operating System: All
 PHP Version:  4.1.1
 New Comment:

Can you try changing the FG(def_chunk_size) assignment
in the file_globals_ctor function in ext/standard/file.c
and hard-code it to 1.
Then try your UDP script.
If that solves the problem, I will add a method of
setting this from script (using set_file_buffer).
I still don't think using recvfrom will make any
difference.


Previous Comments:


[2002-03-16 14:51:31] [EMAIL PROTECTED]

It also says it should only be used in connected sockets.
Here is a working exemple from a porky sourcecode I have :
loop:
len = recvfrom(sock, data, 50, 0, (struct sockaddr *)&sai, &s_sai);
printf("%d bytes from %s:%d -
%s\n",len,inet_ntoa(sai.sin_addr),ntohs(sai.sin_port),data);
goto loop;

The default size is 50, if the UDP packet is < 50 (ie:42) it will print
: 42 bytes from 192.168.0.1:8000 - This is only a test. This is only a
test!!

So if you modify the recv call to a recvfrom call, it won't break TCP
and will make UDP work a better way.



[2002-03-16 12:16:29] [EMAIL PROTECTED]

My man page says that recv is identical to recvfrom with
a NULL from parameter, so I don't see how this can fix
it.
I still don't think this is technically possible over UDP.
If you can show me some real working C code where it works,
I will implement it.



[2002-02-21 20:07:45] [EMAIL PROTECTED]

In C, recvfrom() takes a length argument, but behaves with UDP like
fread should : "Reading stops when length bytes have been read or EOF
is reached, whichever comes first."
Using recvfrom() with length set to 4096 will get the 20 bytes packets
without blocking anything.
The bug has prolly something to do with the use of recv() versus
recvfrom().



[2002-02-20 22:42:53] [EMAIL PROTECTED]

I'll look into UDP sockets in PHP in more detail soon.
In the meantime, I'm not sure that what you are suggesting is possible,
since UDP is a connectionless protocol, how can we detect the end of a
packet/stream?
UDP is supposed to be used with known packet sizes.
If you can show me some C code where what you propose works, I'll
integrate it with the new PHP streams code.
--Wez.



[2002-02-20 07:02:31] [EMAIL PROTECTED]

In fact it's worst than that, setting the socket non-blocking makes
fread not working on unix/win.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15639

-- 
Edit this bug report at http://bugs.php.net/?id=15639&edit=1

Bug #16519 Updated: makefile error

[flim]

 ID:   16519
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: linux redhat 7.2
 PHP Version:  4.1.2
 New Comment:

Hi,
compiled php-4.2.0RC3 on my local linux box with the same errors.
configure runs well, but make creates the 
following output:
Making all in java
make[2]: Wechsel in das Verzeichnis Verzeichnis
»/opt/src/php-4_2_0RC3/ext/java«make[3]: Wechsel in das 
Verzeichnis Verzeichnis »/opt/src/php-4_2_0RC3/ext/java«/bin/sh
/opt/src/php-4_2_0RC3/libtool --silent 
--mode=compile gcc -I. -I/opt/src/php-4_2_0RC3/ext/java
-I/opt/src/php-4_2_0RC3/main -I/opt/src/php-4_2_0RC3 
-I/opt/src/php-4_2_0RC3/Zend -I/opt/src/php-4_2_0RC3/ext/mysql/libmysql

-I/opt/src/php-4_2_0RC3/ext/xml/expat -I/usr/java/j2sdk1.4.0//include
-I/usr/java/j2sdk1.4.0//include/linux 
-I/opt/src/php-4_2_0RC3/TSRM -g -O2 -prefer-pic -DJNI_12 -D_REENTRANT 
'-DJAVALIB="/usr/java/j2sdk1.4.0//./jre/lib/i386/libjava.so"' -c java.c
&& touch java.slo
/opt/src/php-4_2_0RC3/build/shtool mkdir -p net/php
javac net/php/reflect.java
/usr/bin/jar cf php_java.jar net/php/*.class net/php/*.properties
net/php/*.class: no such file or directory
make[3]: *** [php_java.jar] Fehler 2
make[3]: Verlassen des Verzeichnisses Verzeichnis
»/opt/src/php-4_2_0RC3/ext/java«
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/opt/src/php-4_2_0RC3/ext/java«
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis
»/opt/src/php-4_2_0RC3/ext«
make: *** [all-recursive] Fehler 1
this is exactly the same as with php4.1.2. System is a standart
automatically
updated redhat7.2 system. Automatically means, using redhat up2date.
Kernel is .31 at the moment - system is newly installed, all I changed
was removing the php4.0.6 rpms, installing java from current sun rpms
and trying to compile java with the following script:
./configure--with-zlib-dir\
   --enable-pcntl \
   --sbindir=/opt/sbin \
   --bindir=/opt/bin \
   --exec-prefix=/opt \
   --libexecdir=/opt/libexec \
   --datadir=/opt/share \
   --libdir=/opt/lib \
   --program-suffix=4 \
   --with-gd=/usr \
   --enable-sigchild \
   --with-png-dir=/usr/local \
   --with-mysql \
   --enable-shmop\
   --with-gdbm\
   --with-java=/usr/java/j2sdk1.4.0/\
   --enable-ftp
Checking showed the same as before:
in ext/java is a subdirectory structure:
net/php/net/php
where it should only be
net/php
the additional directories are created by the makefile in ext/java, or
better by the line
javac net/php/reflect.java
which creates the reflect.class file to net/php/net/php/reflect.class
instead of net/php/reflect.class...
will try on snapshot version tomorrow;)
good night,
flim


Previous Comments:


[2002-04-12 18:18:46] [EMAIL PROTECTED]

I can not reproduce this with PHP 4.2.0RC3 or latest CVS.
Please try them: http://www.php.net/~derick/ (for the RC3)
http://snaps.php.net/ (snapshots)

--Jani




[2002-04-09 16:51:56] [EMAIL PROTECTED]

Hi,
line 25 of the makefile in ext/java causes a folder construction like
net/php/net/php and put the compiled class in that deepest folder. This
causes the compiler to stop as it cannot find the  file...and if you
move it manually it can't remove the folders;)
this should solve it though (unless you want to train your users;=))
pushd net/php
javac reflect.java
popd

regards,
flim




-- 
Edit this bug report at http://bugs.php.net/?id=16519&edit=1

Bug #16580 Updated: Apache Hang On

[sniper]

 ID:   16580
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Apache related
 Operating System: win98
 PHP Version:  4.1.2
 New Comment:

If it works -> closed.
(remember to update to 4.2.0 when the actual release happens)



Previous Comments:


[2002-04-13 16:39:10] [EMAIL PROTECTED]

Thank You very much!
PHP 42 ORC3 works very good on my system... With upload all now is fine
and works all very fast :)



[2002-04-13 16:38:56] [EMAIL PROTECTED]

Thank You very much!
PHP 42 ORC3 works very good on my system... With upload all now is fine
and works all very fast :)



[2002-04-13 15:25:00] [EMAIL PROTECTED]

could you add some short and complete script into this
bug report which can be used to reproduce this?

And with what browser did you get that?




[2002-04-13 08:59:52] [EMAIL PROTECTED]

ohhh.. I'm sorry... I've just tested with to diferent file size upload
and 3.4Mb file was succesfuly aploaded(very fast etc.. not like with
php4.1.2) but with file 8mb form was posted also very fast but
wariables did not recognized in receiver php file AND in Apache
Error.log file string:
Invalid method in request -7d225814ce0



[2002-04-13 08:53:19] [EMAIL PROTECTED]

With PHP 4.2.0RC3 everything works fine yet but form doesnt post all
variables where one of variable is ... but Apache
doesnt hang on



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16580

-- 
Edit this bug report at http://bugs.php.net/?id=16580&edit=1

Bug #16475 Updated: apache 2.0.35 crashes with php 4.2.0RC2 and RC3

[sniper]

 ID:   16475
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Reproducible crash
+Bug Type: Apache2 related
 Operating System: Linux 2.4.16 / Debian 3.0
 PHP Version:  4.0CVS-02-04-13
 New Comment:

reclassified. (please don't change the category anymore!)



Previous Comments:


[2002-04-13 15:03:55] [EMAIL PROTECTED]

Hi,

well when I do a "ldd /usr/local/bin/httpd" the following list is
shown:

libaprutil.so.0 => /usr/local/apache2/lib/libaprutil.so.0 (0x40016000)
libapr.so.0 => /usr/local/apache2/lib/libapr.so.0 (0x40026000)
libm.so.6 => /lib/libm.so.6 (0x40047000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40069000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40096000)
libdl.so.2 => /lib/libdl.so.2 (0x400ab000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x400af000)
libexpat.so.0 => /usr/local/lib/libexpat.so.0 (0x40135000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40156000)
libc.so.6 => /lib/libc.so.6 (0x4016c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

So there is libpthread included but why not in ldd of libphp4.so (as
seen in my previous postings)? I'm using Debian Woody 3.0 with kernel
2.4.16 and I have installed all recent updates.

Bye,
Sebastian



[2002-04-13 14:15:56] [EMAIL PROTECTED]

Is the libpthread in your system a static library or why
isn't it shown in that ldd list?

Which Debian distro is this anyway? Stable or unstable?




[2002-04-13 07:11:11] [EMAIL PROTECTED]

Hi,

well as [EMAIL PROTECTED] said I tried php 4.2.0RC3 and
latest cvs snapshot from snaps.php.net, but unfortunately the result is
still the same. Maybe some things where fixed but apache still crashes
after being started...see my backtraces:

diebels:/usr/local/apache2/bin# gdb /usr/local/apache2/bin/httpd
/usr/local/apache2/bin/core
GNU gdb 5.1.1
Copyright 2002 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-linux"...
Core was generated by `./httpd -X'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/apache2/lib/libaprutil.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libaprutil.so.0
Reading symbols from /usr/local/apache2/lib/libapr.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libapr.so.0
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libdb-4.0.so...done.
Loaded symbols for /usr/lib/libdb-4.0.so
Reading symbols from /usr/local/lib/libexpat.so.0...done.
Loaded symbols for /usr/local/lib/libexpat.so.0
Reading symbols from /lib/libpthread.so.0...done.

warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 23812)]
Error while reading shared library symbols:
Cannot enable thread event reporting for Thread 1024 (LWP 23812):
generic error
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/apache2/modules/libphp4.so...done.
Loaded symbols for /usr/local/apache2/modules/libphp4.so
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
#0  0x401de657 in malloc () from /lib/libc.so.6
(gdb)bt
#0  0x401de657 in malloc () from /lib/libc.so.6
#1  0x401dfa93 in calloc () from /lib/libc.so.6
#2  0x4037efb9 in zend_hash_init (ht=0x403dec64, nSize=0,
pHashFunction=0, pDestructor=0x40379b04 <_zval_ptr_dtor_wrapper>,
persistent=1) at
/home/sebastian/php_cvs/php4-200204130300/Zend/zend_hash.c:176
#3  0x4037f060 in zend_hash_init_ex (ht=0x403dec64, nSize=0,
pHashFunction=0,
pDestructor=0x40379b04 <_zval_ptr_dtor_wrapper>, persistent=1,
bApplyProtection=0)
at /home/sebastian/php_cvs/php4-200204130300/Zend/zend_hash.c:197
#4  0x4037a169 in register_standard_class () at
/home/sebastian/php_cvs/php4-200204130300/Zend/zend.c:250
#5  0x4037a74f in zend_startup (utility_functions=0xbc78,
extensions=0x0, start_bu

Bug #7643 Updated: APXS compile fails with "not a DSO"

[markonen]

 ID:   7643
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: HP-UX 10.20
 PHP Version:  4.0.3pl1
 New Comment:

So, I guess the question now is that should we continue to 
be "clever" and install apache DSOs with the platform-
specific SHLIB_SUFFIX_NAME or just use .so which is what 
Apache expects. I'm using .so for the Mac OS X build, even 
though .bundle would be the native suffix for the object 
type we're producing.

I.e. it's now time to decide whether this is an Apache or a 
PHP bug.


Previous Comments:


[2002-04-12 06:13:43] [EMAIL PROTECTED]

Read that:

http://aspn.activestate.com/ASPN/Mail/Message/php-install/937938

In fact, what you have to do after "make install" is

- rename /libs/libphp4.sl to libphp4.so

- and run the apxs tooll manually:

/opt/apache/bin/axps -i -a -n php4 >>>
/bin/sh /opt/patches/php-4.1.2/libtool --silent --mode=link gcc
 -I. -I/opt/patches/php-4.1.2/ -I/opt/patches/php-4.1.2/main
-I/opt/patches/php-4.1.2 -I/opt/apache/include
-I/opt/patches/php-4.1.2/Zend -I/opt/mysql/include
-I/opt/patches/php-4.1.2/ext/xml/expat  -DHPUX11 -DMOD_SSL=208107
-DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT
-I/opt/patches/php-4.1.2/TSRM -g -O2 -prefer-pic   -o libphp4.la -rpath
/opt/patches/php-4.1.2/libs -avoid-version
-L/opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.0.1 -L/opt/mysql/lib  -R
/opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.0.1 -R /opt/mysql/lib
stub.lo  Zend/libZend.la  sapi/apache/libsapi.la  main/libmain.la 
regex/libregex.la  ext/mysql/libmysql.la ext/pcre/libpcre.la
ext/posix/libposix.la ext/session/libsession.la
ext/standard/libstandard.la ext/xml/libxml.la  TSRM/libtsrm.la -lpam
-lmysqlclient -lcrypt -lm -lnsl -lgcc -lcrypt

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by
-lmysqlclient.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -lgcc.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
Making all in pear

---END>

Then when attempting to do "make install", here's the real kicker:


<<<---START--

Making install in Zend
Making install in main
Making install in ext
Making install in mysql
Making install in pcre
Making install in pcrelib
Making install in posix
Making install in session
Making install in standard
Making install in xml
Making install in expat
Making install in sapi
Making install in apache
/bin/sh /opt/patches/php-4.1.2/libtool --silent --mode=link gcc
 -I. -I/opt/patches/php-4.1.2/sapi/apache -I/opt/patches/php-4.1.2/main
-I/opt/patches/php-4.1.2 -I/opt/apache/include
-I/opt/patches/php-4.1.2/Zend -I/opt/mysql/include
-I/opt/patches/php-4.1.2/ext/xml/expat  -DHPUX11 -DMOD_SSL=208107
-DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT
-I/opt/patches/php-4.1.2/TSRM -g -O2 -prefer-pic   -o libsapi.la 
sapi_apache.lo mod_php4.lo php_apache.lo
Making install in TSRM
/bin/sh ../libtool --silent --mode=link gcc  -g -O2 -prefer-pic
 -o libtsrm.la   TSRM.lo tsrm_strtok_r.lo tsrm_virtual_cwd.lo
Making install in regex
Making install in .
/bin/sh /opt/patches/php-4.1.2/libtool --silent 

Bug #16580 Updated: Apache Hang On

[juric]

 ID:   16580
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: win98
 PHP Version:  4.1.2
 New Comment:

Thank You very much!
PHP 42 ORC3 works very good on my system... With upload all now is fine
and works all very fast :)


Previous Comments:


[2002-04-13 16:38:56] [EMAIL PROTECTED]

Thank You very much!
PHP 42 ORC3 works very good on my system... With upload all now is fine
and works all very fast :)



[2002-04-13 15:25:00] [EMAIL PROTECTED]

could you add some short and complete script into this
bug report which can be used to reproduce this?

And with what browser did you get that?




[2002-04-13 08:59:52] [EMAIL PROTECTED]

ohhh.. I'm sorry... I've just tested with to diferent file size upload
and 3.4Mb file was succesfuly aploaded(very fast etc.. not like with
php4.1.2) but with file 8mb form was posted also very fast but
wariables did not recognized in receiver php file AND in Apache
Error.log file string:
Invalid method in request -7d225814ce0



[2002-04-13 08:53:19] [EMAIL PROTECTED]

With PHP 4.2.0RC3 everything works fine yet but form doesnt post all
variables where one of variable is ... but Apache
doesnt hang on



[2002-04-12 21:18:42] [EMAIL PROTECTED]

OK! I will try. Thank you
bytheway, that error could be connected with memory_limit?
I have just found that Memory_limit doesnt unrecognized on my windows
system...



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16580

-- 
Edit this bug report at http://bugs.php.net/?id=16580&edit=1

Bug #16580 Updated: Apache Hang On

[juric]

 ID:   16580
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: win98
 PHP Version:  4.1.2
 New Comment:

Thank You very much!
PHP 42 ORC3 works very good on my system... With upload all now is fine
and works all very fast :)


Previous Comments:


[2002-04-13 15:25:00] [EMAIL PROTECTED]

could you add some short and complete script into this
bug report which can be used to reproduce this?

And with what browser did you get that?




[2002-04-13 08:59:52] [EMAIL PROTECTED]

ohhh.. I'm sorry... I've just tested with to diferent file size upload
and 3.4Mb file was succesfuly aploaded(very fast etc.. not like with
php4.1.2) but with file 8mb form was posted also very fast but
wariables did not recognized in receiver php file AND in Apache
Error.log file string:
Invalid method in request -7d225814ce0



[2002-04-13 08:53:19] [EMAIL PROTECTED]

With PHP 4.2.0RC3 everything works fine yet but form doesnt post all
variables where one of variable is ... but Apache
doesnt hang on



[2002-04-12 21:18:42] [EMAIL PROTECTED]

OK! I will try. Thank you
bytheway, that error could be connected with memory_limit?
I have just found that Memory_limit doesnt unrecognized on my windows
system...



[2002-04-12 19:10:57] [EMAIL PROTECTED]

Please test PHP 4.2.0RC3 from http://www.php.net/~derick/
(remember to replace php4ts.dll also!)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16580

-- 
Edit this bug report at http://bugs.php.net/?id=16580&edit=1

Bug #16590 Updated: Problems with strings containing \x00

[jimw]

 ID:   16590
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: PCRE related
+Bug Type: Documentation problem
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

pcre is binary safe with regards to the string being matched against,
but not the pattern. this is a limitation of the pcre library itself,
not just the php interface. you can specify the nul character using:

preg_match("/\\x00/", "foo\0bar")

reclassified as documentation problem.


Previous Comments:


[2002-04-13 15:59:36] [EMAIL PROTECTED]

The docs state that PCRE is binary safe. So this might be a bug after
all...



[2002-04-13 13:23:59] [EMAIL PROTECTED]

Actually, I'm not sure whether this problem can be solved as it is PCRE
and not a PHP specific (and it can't be solved without breaking
compatibilty with languages using 0 terminated strings such as C).

I'm thinking about making it a documentation problem. What do you guys
think?

-daniel



[2002-04-13 13:06:44] [EMAIL PROTECTED]

The PCRE has problems with strings containing 0x00. It stops reading as
if the strings were \0 terminated. This affects all preg_* functions.

Examples:

  preg_match("/\x00/", "foo");
  preg_match("/" . chr(0) . "/", "foo");

Raises the error "Warning: No ending delimiter '/' found"




-- 
Edit this bug report at http://bugs.php.net/?id=16590&edit=1

Bug #16590 Updated: Problems with strings containing \x00

[sander]

 ID:   16590
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

The docs state that PCRE is binary safe. So this might be a bug after
all...


Previous Comments:


[2002-04-13 13:23:59] [EMAIL PROTECTED]

Actually, I'm not sure whether this problem can be solved as it is PCRE
and not a PHP specific (and it can't be solved without breaking
compatibilty with languages using 0 terminated strings such as C).

I'm thinking about making it a documentation problem. What do you guys
think?

-daniel



[2002-04-13 13:06:44] [EMAIL PROTECTED]

The PCRE has problems with strings containing 0x00. It stops reading as
if the strings were \0 terminated. This affects all preg_* functions.

Examples:

  preg_match("/\x00/", "foo");
  preg_match("/" . chr(0) . "/", "foo");

Raises the error "Warning: No ending delimiter '/' found"




-- 
Edit this bug report at http://bugs.php.net/?id=16590&edit=1

Bug #12004 Updated: problem with fopen over ftp and a related fgets

[wez]

 ID:   12004
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Assigned
 Bug Type: *Directory/Filesystem functions
 Operating System: linux
 PHP Version:  4.0.5
-Assigned To:  
+Assigned To:  wez
 New Comment:

We can probably do something about this with the new
streams architecture.
Assigning to myself.


Previous Comments:


[2001-12-17 05:33:01] [EMAIL PROTECTED]

browser changed the title for some reason...



[2001-12-17 05:28:35] [EMAIL PROTECTED]

The following patch will issue a warning for trying to open a ftp file
in anything other than read/write, - as no other methods are supported
by fopen(ftp)

as far as producing errors on 'writing to an ftp file opened read only'
- this is more complex as there is no indicators on the socket to tell
wheter it was opened read or write,

(internally the socket is opened rw as the actual connection is a 2 way
communication)






Index: ftp_fopen_wrapper.c
===
RCS file: /repository/php4/ext/standard/ftp_fopen_wrapper.c,v
retrieving revision 1.11
diff -u -r1.11 ftp_fopen_wrapper.c
--- ftp_fopen_wrapper.c 9 Sep 2001 13:29:18 -   1.11
+++ ftp_fopen_wrapper.c 17 Dec 2001 10:24:06 -
@@ -101,6 +101,14 @@
*issock = BAD_URL;
return NULL;
}
+if (strcmp(mode, "r") &&  strcmp(mode, "w")) {
+   php_error(E_WARNING, "Invalid mode : ftp can only
access files in (r)ead or (w)rite mode");
+   php_url_free(resource);
+   *issock = BAD_URL;
+   return NULL;
+}
+
+
/* use port 21 if one wasn't specified */
if (resource->port == 0)
resource->port = 21;




[2001-10-20 22:40:26] [EMAIL PROTECTED]

Reproduced with PHP 4.1.0RC1

Seems like this is not supported at all..

--Jani




[2001-07-10 06:07:36] [EMAIL PROTECTED]

Configure  './configure'  
'--with-apxs=/usr/local/apache/bin/apxs'
Command'--with-mysql'  '--with-pgsql'  '--with-zlib'
'--enable-ftp'
   '--with-gd'
'--with-jpeg-dir=/usr/local/lib'
   '--enable-versioning' 
'--enable-track-vars=yes'
   '--enable-url-includes'  
'--enable-sysvshm'
   '--enable-syscsem' '--with-gettext'

";
exit;
}

fputs($fp, "test number one...");
fputs($fp, "test number two...");
fputs($fp, "etc...");

fclose($fp);
?>
---
The problem is, that nothing is written in the file even though
fopen,fputs and
fclose do not return an error.

If you use fopen($file, "a+") the strings are written to file. But now
the problem is, that fopen tries to create that file even if it already
exists.

Ciao,
Tobias





-- 
Edit this bug report at http://bugs.php.net/?id=12004&edit=1

Bug #16455 Updated: "Progress Indicator" of some sort in ftp get

[wez]

 ID:   16455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.1.2
 Assigned To:  wez
 New Comment:

Implemented in CVS.
Docs are due later.
Search the php-dev archives for my recent RFC on the
matter which includes a sample script if you can't wait
for the docs.


Previous Comments:


[2002-04-05 15:51:07] [EMAIL PROTECTED]

If that includes checking on connection and login status, 
that'd be perfect (and I'd have no cause to use the ftp 
functions instead). 
 
In fact, if it includes the ability to fetch error 
messages that result, it would be even better 
 
Thanks!



[2002-04-05 15:41:08] [EMAIL PROTECTED]

I aim to provide a means for PHP scripts to check up
on the things that you mentioned for the ftp wrapper
(rather than ftp_get) as part of the streams "refit"
for PHP 4.3



[2002-04-05 12:54:10] [EMAIL PROTECTED]

On long ftp downloads, there appears to be no way to get 
any sort of "progress" indication.  (I prefer to use the 
ftp module rather than the ftp: wrapper for fgets for the 
application in question, so that I can more easily track 
success at connecting, success at logging in, checking of 
ftp directory contents, etc). 
 
This isn't much of an issue on a web-page, where ftp 
download shouldn't take long, but when used as a CLI 
application (as I am currently) to handle a long download, 
it's hard to tell whether or not the download is going 
successfully, or not. 
 
(For simplicity, having output on stderr from the ftp_get 
function as an option would probably be quite 
sufficient...) 




-- 
Edit this bug report at http://bugs.php.net/?id=16455&edit=1

Bug #16580 Updated: Apache Hang On

[sniper]

 ID:   16580
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: win98
 PHP Version:  4.1.2
 New Comment:

could you add some short and complete script into this
bug report which can be used to reproduce this?

And with what browser did you get that?



Previous Comments:


[2002-04-13 08:59:52] [EMAIL PROTECTED]

ohhh.. I'm sorry... I've just tested with to diferent file size upload
and 3.4Mb file was succesfuly aploaded(very fast etc.. not like with
php4.1.2) but with file 8mb form was posted also very fast but
wariables did not recognized in receiver php file AND in Apache
Error.log file string:
Invalid method in request -7d225814ce0



[2002-04-13 08:53:19] [EMAIL PROTECTED]

With PHP 4.2.0RC3 everything works fine yet but form doesnt post all
variables where one of variable is ... but Apache
doesnt hang on



[2002-04-12 21:18:42] [EMAIL PROTECTED]

OK! I will try. Thank you
bytheway, that error could be connected with memory_limit?
I have just found that Memory_limit doesnt unrecognized on my windows
system...



[2002-04-12 19:10:57] [EMAIL PROTECTED]

Please test PHP 4.2.0RC3 from http://www.php.net/~derick/
(remember to replace php4ts.dll also!)




[2002-04-12 19:05:24] [EMAIL PROTECTED]

I use PHP 4.12 like a module of Apache 1322...
With php.ini all OK...
When I try to upload file larger than 5Mb than apears error:
FATAL:  erealloc():  Unable to allocate 5784001 bytes
And Apache hangs on...
The same problem was with older php and apache versions...
Help Please or give me the Link where is solve this problem
Thank You




-- 
Edit this bug report at http://bugs.php.net/?id=16580&edit=1

Bug #16475 Updated: apache 2.0.35 crashes with php 4.2.0RC2 and RC3

[sebastian . wolfgarten]

 ID:   16475
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
-Bug Type: Apache2 related
+Bug Type: Reproducible crash
 Operating System: Linux 2.4.16 / Debian 3.0
 PHP Version:  4.0CVS-02-04-13
 New Comment:

Hi,

well when I do a "ldd /usr/local/bin/httpd" the following list is
shown:

libaprutil.so.0 => /usr/local/apache2/lib/libaprutil.so.0 (0x40016000)
libapr.so.0 => /usr/local/apache2/lib/libapr.so.0 (0x40026000)
libm.so.6 => /lib/libm.so.6 (0x40047000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40069000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40096000)
libdl.so.2 => /lib/libdl.so.2 (0x400ab000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x400af000)
libexpat.so.0 => /usr/local/lib/libexpat.so.0 (0x40135000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40156000)
libc.so.6 => /lib/libc.so.6 (0x4016c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

So there is libpthread included but why not in ldd of libphp4.so (as
seen in my previous postings)? I'm using Debian Woody 3.0 with kernel
2.4.16 and I have installed all recent updates.

Bye,
Sebastian


Previous Comments:


[2002-04-13 14:15:56] [EMAIL PROTECTED]

Is the libpthread in your system a static library or why
isn't it shown in that ldd list?

Which Debian distro is this anyway? Stable or unstable?




[2002-04-13 07:11:11] [EMAIL PROTECTED]

Hi,

well as [EMAIL PROTECTED] said I tried php 4.2.0RC3 and
latest cvs snapshot from snaps.php.net, but unfortunately the result is
still the same. Maybe some things where fixed but apache still crashes
after being started...see my backtraces:

diebels:/usr/local/apache2/bin# gdb /usr/local/apache2/bin/httpd
/usr/local/apache2/bin/core
GNU gdb 5.1.1
Copyright 2002 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-linux"...
Core was generated by `./httpd -X'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/apache2/lib/libaprutil.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libaprutil.so.0
Reading symbols from /usr/local/apache2/lib/libapr.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libapr.so.0
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libdb-4.0.so...done.
Loaded symbols for /usr/lib/libdb-4.0.so
Reading symbols from /usr/local/lib/libexpat.so.0...done.
Loaded symbols for /usr/local/lib/libexpat.so.0
Reading symbols from /lib/libpthread.so.0...done.

warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 23812)]
Error while reading shared library symbols:
Cannot enable thread event reporting for Thread 1024 (LWP 23812):
generic error
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/apache2/modules/libphp4.so...done.
Loaded symbols for /usr/local/apache2/modules/libphp4.so
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
#0  0x401de657 in malloc () from /lib/libc.so.6
(gdb)bt
#0  0x401de657 in malloc () from /lib/libc.so.6
#1  0x401dfa93 in calloc () from /lib/libc.so.6
#2  0x4037efb9 in zend_hash_init (ht=0x403dec64, nSize=0,
pHashFunction=0, pDestructor=0x40379b04 <_zval_ptr_dtor_wrapper>,
persistent=1) at
/home/sebastian/php_cvs/php4-200204130300/Zend/zend_hash.c:176
#3  0x4037f060 in zend_hash_init_ex (ht=0x403dec64, nSize=0,
pHashFunction=0,
pDestructor=0x40379b04 <_zval_ptr_dtor_wrapper>, persistent=1,
bApplyProtection=0)
at /home/sebastian/php_cvs/php4-200204130300/Zend/zend_hash.c:197
#4  0x4037a169 in register_standard_class () at
/home/sebastian/php_cvs/php4-200204130300/Zend/zend.c:250
#5  0x4037a74f in zend_startup (utility_functions=0xbc78,
extensions=0x0, start_builtin_functions=1)
at /home/sebastian/php_cvs/php4-200204130300/Zend/zend.c:429
#6  0x4034dbbd in php_module_startup (sf=0x403cc440) at
/home/

Bug #14011 Updated: Segmentation fault on connect to Interbase

[daniela]

 ID:   14011
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Linux Slackware 7.1
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".




Previous Comments:


[2001-11-10 17:17:25] [EMAIL PROTECTED]

when doing this:

$sth = ibase_connect ($database, $username, $password)

it ends up with segmentation fault, the script stops to execute and
nothing is returned to apache server

On another similar Linux server the connection proceeds but the script
gives the same  error message in function $row = ibase_fetch_object
($sth). Insteed the script continues executing and the data are
fetched.


On both servers Apache and PHP configurations are equivalent
PHP is compiled with 
./configure --with-apxs=/usr/var/lib/apache/sbin/apxs --with-interbase
--without-mysql





-- 
Edit this bug report at http://bugs.php.net/?id=14011&edit=1

Bug #12052 Updated: BUG #12006

[daniela]

 ID:   12052
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: winme
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".


Previous Comments:


[2001-07-11 10:04:31] [EMAIL PROTECTED]

BUG id #12006
Dear Derick
/* Table: LOTTERY, Owner: SYSDBA */

CREATE TABLE "LOTTERY" 
(
  "INSTALL1"DATE NOT NULL,
  "RATE1"   NUMERIC(9, 2),
  "INSTALL2"DATE,
  "RATE2"   NUMERIC(9, 2),
  "TOTAL"COMPUTED BY (rate1 + rate2),
CONSTRAINT "pkLOTTERY" PRIMARY KEY ("INSTALL1")
);
The above is my table structure.
the following is my php code that produce previous mentioned bug.
ibase_timefmt("%d/%m/%Y", IBASE_DATE);
$db = ibase_pconnect('c:/mydb.gdb', 'SYSDBA', 'masterkey');
$query = "select * from lot";
$result = ibase_query($db, $query );
$sum = 0;
$rowcount = 0;
print "Lottery";
print "";
print
"DATE01TOTAL1DATE16TOTAL2TOTALSUM";

 while( $row = ibase_fetch_row( $result )){
  $s = sprintf( "$row[0]%s$row[2]%s%s", number_format($row[1], 2),number_format($row[3],
2), number_format($row[4], 2));
  print $s;
  $sum += $row[4];
  $rowcount++;
}
 ibase_free_result($result);
 ibase_commit();
 ibase_close($db);
  sorry for any incoutesy I'm very novice for responding by this
system.




-- 
Edit this bug report at http://bugs.php.net/?id=12052&edit=1

Bug #11530 Updated: PATCH: InterBase/Firebird Decimal/Numeric type returns incorrect value type

[daniela]

 ID:   11530
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Debian Linux
 PHP Version:  4.0.5
 New Comment:

This is already be fixed.

The version of PHP that this bug was reported in is too old.
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 
and if you are still able to reproduce this bug feel free to reopen it


Previous Comments:


[2001-06-18 00:53:52] [EMAIL PROTECTED]

ibase_query() returns incorrect value about Decimal/Numeric type on
InterBase6/Firebird.

--- interbase.c.origFri Jun 15 11:32:31 2001
+++ interbase.c Tue Jun 12 18:09:07 2001
@@ -1741,7 +1741,22 @@
val->value.str.len = len;
break;
case SQL_LONG:
-   if (scale) {
+   if (scale < 0) {
+   int j;
+   long dt, dth, dtl, pow_scale = 1;
+   for (j = 0; j < -scale; j++) pow_scale *= 10;
+   dt = *(long *)data;
+   dth = dt / pow_scale;
+   dtl = dt % pow_scale;
+   if (dtl < 0) dtl *= -1;
+   if ((dt < 0) && (dth == 0)) {
+   val->value.str.len = sprintf(string_data, 
+"-0.%0*ld", -scale,
dtl);
+   } else {
+   val->value.str.len = sprintf(string_data, 
+"%ld.%0*ld", dth,
-scale, dtl);
+   }
+   val->type = IS_STRING;
+   val->value.str.val = estrdup(string_data);
+   /*
int j, f = 1;
float n = (float) *(long *)(data);

@@ -1750,18 +1765,36 @@
val->type = IS_STRING;
val->value.str.len = sprintf(string_data, "%.*f", 
-scale, n / f);
val->value.str.val = estrdup(string_data);
+   */
} else {
val->type = IS_LONG;
val->value.lval = *(long *)(data);
}
break;
case SQL_SHORT:
-   val->type = IS_LONG;
-   val->value.lval = *(short *)(data);
+   if (scale < 0) {
+   int j;
+   short dt, dth, dtl, pow_scale = 1;
+   for (j = 0; j < -scale; j++) pow_scale *= 10;
+   dt = *(short *)data;
+   dth = dt / pow_scale;
+   dtl = dt % pow_scale;
+   if (dtl < 0) dtl *= -1;
+   if ((dt < 0) && (dth == 0)) {
+   val->value.str.len = sprintf(string_data, 
+"-0.%0*hd", -scale,
(int)dtl);
+   } else {
+   val->value.str.len = sprintf(string_data, 
+"%hd.%0*hd", (int)dth,
-scale, (int)dtl);
+   }
+   val->type = IS_STRING;
+   val->value.str.val = estrdup(string_data);
+   } else {
+   val->type = IS_LONG;
+   val->value.lval = *(short *)(data);
+   }
break;
case SQL_FLOAT:
val->type = IS_DOUBLE;
-   val->value.dval = *(float *)(data);
+   val->value.dval = (double) *(float *)(data);
break;
case SQL_DOUBLE:
if (scale) {
@@ -1778,11 +1811,31 @@
break;
 #ifdef SQL_INT64
case SQL_INT64:
-   val->type = IS_STRING;
+   if (scale) {
+   int j;
+   ISC_INT64 dt, dth, dtl, pow_scale = 1;
+   for (j = 0; j < -scale; j++) pow_scale *= 10;
+   dt = *(ISC_INT64 *)data;
+   dth = (ISC_INT64) (dt / pow_scale);
+   dtl = (ISC_INT64) (dt % pow_scale);
+   if (dtl < 0) dtl *= -1;
+   if ((dt < 0) && (dth == 0)) {
+

Bug #14328 Updated: Interbase and error handling

[daniela]

 ID:   14328
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Linux Red Hat 7.1
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".



Previous Comments:


[2001-12-03 14:58:23] [EMAIL PROTECTED]

This may can't be exactly a bug, maybe you can consider it as a not
implemented feature (I'm not sure about it).

Well, when I'm triying to handle error generated by any Interbase
function, it doesn't work. When I try the same with a MySQL function
all goes ok. I'm interested in show my own error messages but it's
imposible to handle any error generated by Interbase function. I have
tried with error_handling(0), with the @ operator before the function,
putting error_handling to 0 and ~E_ALL in PHP.INI but Interbase
function always returns it own error message.

For example I have this code in a object constructor:

$this->IBConnection = @ibase_connect($this->SQLEDatabase,
$this->SQLEUser, $this->SQLEPass, 'NONE', '0', '3');
if (!$this->IBConnection)
   trigger_error("No se pudo conectar con la base de datos",
E_USER_ERROR);

Then, it first shows me the default error message and then my own
generated error message...




-- 
Edit this bug report at http://bugs.php.net/?id=14328&edit=1

Bug #15314 Updated: php can't handle values of type double correcty

[daniela]

 ID:   15314
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: win32
 PHP Version:  4.1.1
 New Comment:

This bug it's been fixed.
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".


Previous Comments:


[2002-01-31 08:43:51] [EMAIL PROTECTED]

PHP interbase can't seem to handle fieldtypes declared as type
numeric(x,y). It always returns any value stored in these fields as
xyz.y Thus if the value in the interbase database is 4.6 and the
fieldtype was declared as numeric(15,4) php returns 4.4 instead of 4.6.
It seems that it is appending the precision value instead of the part
after the decimal separator.




-- 
Edit this bug report at http://bugs.php.net/?id=15314&edit=1

Bug #13807 Updated: Incorrect display of NUMERIC(15,2) data

[daniela]

 ID:   13807
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Windows
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".


Previous Comments:


[2001-10-24 02:24:02] [EMAIL PROTECTED]

Using NUMERIC(15,2) in Windows IB6 as money fields all displays on the
web page appears as ###.20. For example 123.45 appears as 123.20. The
precision value seems to be displayed instead of the actual decimal
value.
I believe the same is happening with DECIMAL(?.?) 

P.S. I keep getting the W32.HLLW.Bymer virus going into pHp.com.





-- 
Edit this bug report at http://bugs.php.net/?id=13807&edit=1

Bug #14039 Updated: Invalid statement handle

[daniela]

 ID:   14039
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Windows NT 4 SP 4
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".

This bug should be fixed now.
You were right, the problem was in ibase_close().
However have a look at:
http://www.php.net/manual/en/function.ibase-close.php

Daniela






Previous Comments:


[2001-11-13 04:41:52] [EMAIL PROTECTED]

When exiting a function after having closed a link to Interbase, the
warning "Invalid statement handle" is displayed. apparently, PHP tries
to close the connection by itself even if it has already been closed,
which raises this warning from interbase.

Example :





-- 
Edit this bug report at http://bugs.php.net/?id=14039&edit=1

Bug #16588 Updated: Extra EXIF headers

[sniper]

 ID:   16588
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  4.1.2
 New Comment:

There has been lot of changes in the EXIF extension lately.
But most of the new stuff didn't make it in time for the
4.2.0 release. Please try the latest CVS snapshot from
http://snaps.php.net/ and check the php-cvs/php-dev mailing
lists for more information what has been changed/added.



Previous Comments:


[2002-04-13 08:31:14] [EMAIL PROTECTED]

Hello there. I have been investigating the EXIF tags that Windows XP
can add to files, and have successfully identified five extra tags and
their mappings to the fields on the File|Properties...|Summary tab in
Explorer (both "simple" and "advanced" views). XP ignores the standard
UserComment field, alas, so I was forced to look into this.

(For those not using XP to manage their photos, Explorer allows you to
view most EXIF data within the File|Properties... dialog, and even add
some EXIF fields as columns in Detail view)

Since I don't have CVS access, or even a PHP development environment
that would allow me to do the necessary changes myself, I am posting
this here in hope that someone will add this to the upcoming 4.2.0
release.

I suggest the following entries for the TagTable:

static const struct {  
  unsigned short Tag;  
  char *Desc;  
} TagTable[] = {  
{ 0x00FE, "NewSubFile"},  
{ 0x00FF, "SubFile"},  

...

{ 0x9c9b, "Title" }, // Win XP specific, Unicode 
{ 0x9c9c, "Comments" },  // Win XP specific, Unicode 
{ 0x9c9d, "Author" },// Win XP specific, Unicode 
{ 0x9c9e, "Keywords" },  // Win XP specific, Unicode 
{ 0x9c9f, "Subject" },   // Win XP specific, Unicode, not to be
confused with SubjectDistance and SubjectLocation




-- 
Edit this bug report at http://bugs.php.net/?id=16588&edit=1

Bug #16475 Updated: apache 2.0.35 crashes with php 4.2.0RC2 and RC3

[sniper]

 ID:   16475
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: Reproducible crash
+Bug Type: Apache2 related
 Operating System: Linux 2.4.16 / Debian 3.0
 PHP Version:  4.0CVS-02-04-13
 New Comment:

Is the libpthread in your system a static library or why
isn't it shown in that ldd list?

Which Debian distro is this anyway? Stable or unstable?



Previous Comments:


[2002-04-13 07:11:11] [EMAIL PROTECTED]

Hi,

well as [EMAIL PROTECTED] said I tried php 4.2.0RC3 and
latest cvs snapshot from snaps.php.net, but unfortunately the result is
still the same. Maybe some things where fixed but apache still crashes
after being started...see my backtraces:

diebels:/usr/local/apache2/bin# gdb /usr/local/apache2/bin/httpd
/usr/local/apache2/bin/core
GNU gdb 5.1.1
Copyright 2002 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-linux"...
Core was generated by `./httpd -X'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/apache2/lib/libaprutil.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libaprutil.so.0
Reading symbols from /usr/local/apache2/lib/libapr.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libapr.so.0
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libdb-4.0.so...done.
Loaded symbols for /usr/lib/libdb-4.0.so
Reading symbols from /usr/local/lib/libexpat.so.0...done.
Loaded symbols for /usr/local/lib/libexpat.so.0
Reading symbols from /lib/libpthread.so.0...done.

warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 23812)]
Error while reading shared library symbols:
Cannot enable thread event reporting for Thread 1024 (LWP 23812):
generic error
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/apache2/modules/libphp4.so...done.
Loaded symbols for /usr/local/apache2/modules/libphp4.so
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
#0  0x401de657 in malloc () from /lib/libc.so.6
(gdb)bt
#0  0x401de657 in malloc () from /lib/libc.so.6
#1  0x401dfa93 in calloc () from /lib/libc.so.6
#2  0x4037efb9 in zend_hash_init (ht=0x403dec64, nSize=0,
pHashFunction=0, pDestructor=0x40379b04 <_zval_ptr_dtor_wrapper>,
persistent=1) at
/home/sebastian/php_cvs/php4-200204130300/Zend/zend_hash.c:176
#3  0x4037f060 in zend_hash_init_ex (ht=0x403dec64, nSize=0,
pHashFunction=0,
pDestructor=0x40379b04 <_zval_ptr_dtor_wrapper>, persistent=1,
bApplyProtection=0)
at /home/sebastian/php_cvs/php4-200204130300/Zend/zend_hash.c:197
#4  0x4037a169 in register_standard_class () at
/home/sebastian/php_cvs/php4-200204130300/Zend/zend.c:250
#5  0x4037a74f in zend_startup (utility_functions=0xbc78,
extensions=0x0, start_builtin_functions=1)
at /home/sebastian/php_cvs/php4-200204130300/Zend/zend.c:429
#6  0x4034dbbd in php_module_startup (sf=0x403cc440) at
/home/sebastian/php_cvs/php4-200204130300/main/main.c:924
#7  0x40392713 in php_apache_server_startup (pconf=0x80ad520,
plog=0x80e5600, ptemp=0x812f3e0, s=0x8131a48)
at
/home/sebastian/php_cvs/php4-200204130300/sapi/apache2filter/sapi_apache2.c:435
#8  0x08076e51 in ap_run_post_config (pconf=0x80ad520, plog=0x80e5600,
ptemp=0x812f3e0, s=0x8131a48) at config.c:129
#9  0x0807b031 in main (argc=2, argv=0xbdd4) at main.c:611
#10 0x401896cf in __libc_start_main () from /lib/libc.so.6

I will try it again in a couple of days...

Bye,
Sebastian



[2002-04-12 20:25:45] [EMAIL PROTECTED]

There have been some fixes. Please try PHP 4.2.0RC3
from http://www.php.net/~derick/ or latest CVS snapshot
from http://snaps.php.net/




[2002-04-07 12:57:31] [EMAIL PROTECTED]

Well,

it's me again :-)
I just compiled php with --with-a

Bug #16585 Updated: Use of $_SESSION to set variable doesn't save variable

[sniper]

 ID:   16585
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Windows XP
 PHP Version:  4.1.2
 New Comment:

It's propably the same issue as everyone else is having.
Please try the PHP 4.2.0RC3 from http://www.php.net/~derick/
as others have reported that it works fine for them.

And don't forget to replace the php4ts.dll in your system
with the one in the 4.2.0RC3 package.



Previous Comments:


[2002-04-13 06:50:03] [EMAIL PROTECTED]

Following the 'Session handling' documentation and expriencing problems
with a production script, I wrote the following test script:

test.php:
\r\n";
if( !isset( $_SESSION['Test'] ) )
{
$_SESSION['Test'] = "bla bla bla";
echo "Defined : ".$_SESSION['Test']."\r\n";
}
else
{
echo "Existing : ".$_SESSION['Test']."\r\n";
}
//session_write_close();
?>

which I expect to set the 'Test' session variable on the first call to
the page and then return the 'Test' session variable on subsequent
calls to the script.

This works FINE with PHP 4.1.1 but DOES NOT WORK with PHP 4.1.2 (though
the session ID is the same). I had to revert to the old
'session_register()' function for the script to work in PHP 4.1.2,
$HTTP_SESSION_VARS not working either.

Any clue ?

Ce.D




-- 
Edit this bug report at http://bugs.php.net/?id=16585&edit=1

Bug #16591: class loading in unserialize/session_decode

[tthiery]

From: [EMAIL PROTECTED]
Operating system: Linux/Win2k/whatever
PHP version:  4.1.2
PHP Bug Type: Feature/Change Request
Bug description:  class loading in unserialize/session_decode

I define classes in extra scripts like this one: 

File: hello.class.php 
 

I include and create them via a manufacturing function: 
$obj = myCreateObject("Hello"); 
myCreateObject lookup the file for Hello, include_once them, create the
object and returns it. 
But then the problem: I store the object to session and when I unserialize
the object in the next script, an error occurs. Clear, the class script
file isn't loaded. Until now I do the serialize/unserialize via a trick (a
register_shutdown_function store all of these objects AND their meta data
like classname in one session var and in the next script all of them are
unserialized manually). 

My Question: Is in the unserialize function and/or the session_decode
function a possibility of a callback function like myLoadClass("Hello")
for a serialized object (class Hello) ? 

And if the answer is a no: Hey PHP team it's an idea for a new function. 

ps I post this message already in the zend.com forum PHP into future
-- 
Edit bug report at http://bugs.php.net/?id=16591&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16591&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16591&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16591&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16591&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16591&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16591&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16591&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16591&r=submittedtwice

Bug #16578 Updated: Build Fails, relevance to apache

[dport113]

 ID:   16578
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux Kernel 2.4.18
 PHP Version:  4.1.2
 New Comment:

Ok Ive tried configuring PHP4.x (ORC1/ORX2 as well) with the options as
follows:
./configure --with-mysql --with-apxs2=/www/bin/apxs
make (fails)
With the same results on all systems.


Previous Comments:


[2002-04-12 18:43:36] [EMAIL PROTECTED]

The correct configure option is --with-apxs2 (notice the number 2
there?)





[2002-04-12 18:40:43] [EMAIL PROTECTED]

Upon building PHP4.x.x (including RC1/RC2/CVS) on Apache 2.0.x
(currently 2.0.35) The make fails on this:
sapi_apache.c: In function `apache_php_module_main':
sapi_apache.c:81: `NOT_FOUND' undeclared (first use in this function)
sapi_apache.c:81: (Each undeclared identifier is reported only once
sapi_apache.c:81: for each function it appears in.)
make[3]: *** [sapi_apache.lo] Error 1
make[3]: Leaving directory `/usr/local/php-4.2.0RC1/sapi/apache'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/php-4.2.0RC1/sapi/apache'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/php-4.2.0RC1/sapi'
make: *** [all-recursive] Error 1

Apache was configured in the following :
./configure --prefix=/www --enable-so --enable-ssl
make 
make insall
PHP 4.x was configured in the following:
./configure --with-mysql --with-apxs=/www/bin/apxs
make (failed)

RH7.296 (7.3beta) Kernel 2.4.18grsec1.94 / GCC3.0.4 / Apache 2.0.35 mod
ssl/so

Im aware of known issues with 4.2.xRC1/RC2 with Apache 2.0.x
This is reproducable on several systems of mine 
RH7.1 Kernel 2.4.16 / GCC2.96 / Apache 2.0.35
RH7.0 Kernel 2.2.23 / GCC2.95 / Apache 2.0.34
SuSE 7.3 Kernel 2.4.7 (SuSE Optimizations left in place) GCC3.0.4 /
Apache 2.0.34

Any help on this is appreciated if it is merely a(n) error on my part.
I do have a succesfull build on:
RH7.2 Kernel 2.4.16grsec1.93 / GCC3.0.4 / Apache 1.3.23/24

Thanks.
David Portwood 




-- 
Edit this bug report at http://bugs.php.net/?id=16578&edit=1

Bug #11176 Updated: Bad results when retrieving IB decimal/float data type from stored procedures

[daniela]

 ID:   11176
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Any
 PHP Version:  4.0.5
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".


Previous Comments:


[2001-05-29 17:44:06] [EMAIL PROTECTED]

Hi there,

Reposted from somewhere else:

-
Anyone who are using PHP + Interbase should be aware of this bugs
especially
when trying to retrieve IB decimal/float data type from a stored
procedure(s). I have reproduced this error that seems as a bug on PHP
when
retrieving data from ib that could be found in the attached file.

i tried to execute this query from IBConsole:

SELECT * FROM TEST_P;

and the result is:

94000581000
85000587000
27058581000
12334547000
12345678000

while PHP shows:

-488699512.21
-898758920.19
1288777224.6
-550354888.2
-539223888.2


-Jaimy

 TEST.SQL ---

create table test (
tbvalue decimal(18,3)
);
commit work;
insert into test values(94000581);
insert into test values(85000587);
insert into test values(27058581);
insert into test values(12334547);
insert into test values(12345678);
commit work;

set term ^;
create procedure test_p
returns (
   spvalue   decimal(18,3)
) as
begin
   for select tbValue from test into :spvalue do
   begin
spvalue = spvalue * 1000;
suspend;
   end
end
^
set term ;^
commit work;

--- TEST.PHP -
";
}
ibase_close($dbh);

?>
-


By the way, thanks for such a great product as PHP!

Best Regards,

Jorge Alvarez




-- 
Edit this bug report at http://bugs.php.net/?id=11176&edit=1

Bug #11154 Updated: Invalid Result on IB Decimal/Float datatype called from stored procedure

[daniela]

 ID:   11154
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Win2000Pro/Slackware Linux 7.1
 PHP Version:  4.0.5
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".


Previous Comments:


[2001-05-28 07:35:23] [EMAIL PROTECTED]

Interbase 6.01 Win: 
http://mers.com/ib_wi_os_010527.exe
Interbase 6.01 Linux: 
http://mers.com/InterBaseCS_LI-V6.0.1.tar
-  TEST.SQL ---
SET SQL DIALECT 3;
/*

CREATE DATABASE 'd:\currdata\test.gdb' PAGE_SIZE 4096 
DEFAULT CHARACTER SET;

*/
 
create table test (
tbvalue decimal(18,3)
);
commit work;
insert into test values(94000581);
insert into test values(85000587);
insert into test values(27058581);
insert into test values(12334547);
insert into test values(12345678);
commit work;

set term ^;
create procedure test_p
returns (
   spvalue   decimal(18,3)
) as
begin
   for select tbValue from test into :spvalue do
   begin
spvalue = spvalue * 1000;
suspend;
   end
end
^
set term ;^
commit work;
select * from test_p;
-- TEST.PHP --
";
}
ibase_close($dbh);

?>
-- COPY OF RESULT --

-488699512.21
-898758920.19
1288777224.6
-550354888.2
-539223888.2

should be:

94000581000
85000587000
27058581000
12334547000
12345678000

-- COPY OF PHP.INI 

[PHP]
; $Id: php.ini-dist,v 1.73.2.2 2001/04/22 11:58:49 phanto Exp $

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP
to
; read it, it must be named 'php.ini'.  PHP looks for it in the
current
; working directory, in the path designated by the environment
variable
; PHPRC, and in the path that was defined in compile time (in that
order).
; Under Windows, the compile-time path is the Windows directory.  The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple.  Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably
guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from
FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or
M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an
expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and
parentheses:
; |bitwise OR
; &bitwise AND
; ~bitwise NOT
; !boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after
the equal
; sign, or by using the None keyword:
;
;  foo = ; sets foo to an empty string
;  foo = none; sets foo to an empty string
;  foo = "none"  ; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a
; dynamically loaded extension (either a PHP extension or a Zend
extension),
; you may only use these constants *after* the line that loads the
extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these
lines,
; the builtin defaults will be identical).



; Language Options ;


; Enable the PHP scripting language engine under Apache.
engine = On

; Allow the  tags are
recognized.
short_open_tag = On

; Allow ASP-style <% %> tags.
asp_tags = Off

; The number of significant digits displayed in floating point
numbers.
precision=  14

; Enforce year 2000 compliance (will cause problems with non-compliant
browsers)
y2k_compliance = Off

; Output buffering allows you to send header lines (including cookies)
even
; after you send body content, at the price of slowing PHP's output
layer a
; bit.  You can enable output buffering during runtime by calling the
output
; buffering functions.  You can also enable output buffering for all
files by
; setting this directive to On.
output_buffering = Off

; You can redirect all of the output of yo

Bug #11631 Updated: php_interbase.dll problem

[daniela]

 ID:   11631
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Windows
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php 4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".



Previous Comments:


[2001-06-24 05:23:29] [EMAIL PROTECTED]

Hi there,
I found something strange about the php_interbase.dll included in
versions 4.0.6 and
4.0.5. Both dlls in the different versions have the same size, but they
return diffrent results
from a sql query that uses agregate SUM().
All I do is to select from the table, SUM the results and display them
out. When I use the
dll included in 4.0.5 the results are acurate. When I use the dll
included in 4.0.6 with
php 4.0.6 instead of exact numbers like 25.0 , I receive 25.2  and this
is in all my results
( + 0.2 ).





[2001-06-23 14:39:29] [EMAIL PROTECTED]

Hi there,
I found something strange about the php_interbase.dll included in
versions 4.0.6 and 4.0.5. Both dlls in the different versions have the
same size, but they return diffrent results from a sql query that uses
agregate SUM().
All I do is to select from the table, SUM the results and display them
out. When I use the dll included in 4.0.5 the results are acurate. When
I use the dll included in 4.0.6 with php 4.0.6 instead of exact numbers
like 25.0 , I receive 25.2  and this is in all my results ( + 0.2 ).





-- 
Edit this bug report at http://bugs.php.net/?id=11631&edit=1

Bug #10948 Updated: Apache can't load with php_interbase.dll

[daniela]

 ID:   10948
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: Win2K
 PHP Version:  4.0.5
 New Comment:

The version of PHP that this bug was reported in is too old. 
Please try the php-4.2.0RC3 from http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change 
the status back to "Open".



Previous Comments:


[2001-05-18 04:00:07] [EMAIL PROTECTED]

I have Apache 1.3.19 running as an NT service on Win2K sp1 with php
loaded as a module.  If I try to enable interbase support by
uncommenting the line

extension=php_interbase.dll

then apache cannot start.  if i try and start it through the Services
panel, i get the following message:

"Could not start the Apache service on Local Computer.  The service did
not return an error.  This could be an internal Windows error or an
internal service error"

if i do it on the command line, i get:

"[Fri May 18 04:04:02 2001] [emerg] <2>The system cannot find the file
specified: OpenEvent on ap2024_restart event"






-- 
Edit this bug report at http://bugs.php.net/?id=10948&edit=1

Bug #16590 Updated: Problems with strings containing \x00

[daniel]

 ID:   16590
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

Actually, I'm not sure whether this problem can be solved as it is PCRE
and not a PHP specific (and it can't be solved without breaking
compatibilty with languages using 0 terminated strings such as C).

I'm thinking about making it a documentation problem. What do you guys
think?

-daniel


Previous Comments:


[2002-04-13 13:06:44] [EMAIL PROTECTED]

The PCRE has problems with strings containing 0x00. It stops reading as
if the strings were \0 terminated. This affects all preg_* functions.

Examples:

  preg_match("/\x00/", "foo");
  preg_match("/" . chr(0) . "/", "foo");

Raises the error "Warning: No ending delimiter '/' found"




-- 
Edit this bug report at http://bugs.php.net/?id=16590&edit=1

Bug #10872 Updated: Cannot load php_Interbase.dll extension...

[daniela]

 ID:   10872
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: InterBase related
 Operating System: WinNT - InterBase 6.0Free
 PHP Version:  4.0.5
 New Comment:

The version of PHP that this bug was reported in is too old. Please try
the php 4.2.0RC3 from
http://www.php.net/~derick/ 

If you are still able to reproduce the bug, please change the PHP
version on this bug report to the version you tested and change the
status back to "Open".



Previous Comments:


[2001-05-15 05:21:37] [EMAIL PROTECTED]

show an "ordinal 261 could not be located in GDS32.dll" error message,
and cannot load interbase dll. Wihtout this I can use PHP.ini, but I
want to use InterBase (client).
I work with the newest PHP version donwloaded from PHP.net.
php_interbase.dll 40960 byte
gds32.dll (winNT/system32) 332288 byte

Thank you,
best regards




-- 
Edit this bug report at http://bugs.php.net/?id=10872&edit=1

Bug #16590: Problems with strings containing \x00

[daniel]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.2
PHP Bug Type: PCRE related
Bug description:  Problems with strings containing \x00

The PCRE has problems with strings containing 0x00. It stops reading as if
the strings were \0 terminated. This affects all preg_* functions.

Examples:

  preg_match("/\x00/", "foo");
  preg_match("/" . chr(0) . "/", "foo");

Raises the error "Warning: No ending delimiter '/' found"
-- 
Edit bug report at http://bugs.php.net/?id=16590&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16590&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16590&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16590&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16590&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16590&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16590&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16590&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16590&r=submittedtwice

Bug #16589 Updated: php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error

[msopacua]

 ID:   16589
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Zlib Related
 Operating System: PLD Linux
 PHP Version:  4.2.0RC3
 New Comment:

First update php.ini to reflect the correct extension dir. You're using
a lib compiled with debug=1 and a php version without.

The extension dir, then changes.


Previous Comments:


[2002-04-13 11:21:18] [EMAIL PROTECTED]

Fix version.



[2002-04-13 11:20:41] [EMAIL PROTECTED]

php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error:

#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) bt
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
#1  0x00839856 in php_log_err (
log_message=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"..., tsrm_ls=0x1775ff0) at
main.c:324
#2  0x00839d57 in php_error_cb (type=32, error_filename=0x8e8f2b
"Unknown", error_lineno=0, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n", 
args=0xb758 "wâ|") at main.c:459
#3  0x0082c917 in zend_error (type=32, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n") at zend.c:682
#4  0x0088cd51 in php_dl (file=0x1d46ff0, type=1,
return_value=0xb7c0, tsrm_ls=0x1775ff0) at dl.c:202
#5  0x0083f5c3 in php_load_function_extension_cb (arg=0x1d46ff0,
tsrm_ls=0x1775ff0) at php_ini.c:188
#6  0x008244cd in zend_llist_apply (l=0x915f3c, func=0x83f58a
, tsrm_ls=0x1775ff0)
at zend_llist.c:186
#7  0x0083faa4 in php_ini_delayed_modules_startup (tsrm_ls=0x1775ff0)
at php_ini.c:313
#8  0x0083ba4b in php_module_startup (sf=0x77a020) at main.c:1001
#9  0x00778ca3 in php_apache_server_startup (pconf=0x4d4010,
plog=0x513010, ptemp=0x516010, s=0x4fe118)
at sapi_apache2.c:435
#10 0x080681e5 in ap_run_post_config (pconf=0x4d4010, plog=0x513010,
ptemp=0x516010, s=0x4fe118) at config.c:130
#11 0x0806e545 in main (argc=2, argv=0xb9e4) at main.c:569
#12 0x003c0418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) print ctx
$8 = (struct php_struct *) 0x0
(gdb) 





-- 
Edit this bug report at http://bugs.php.net/?id=16589&edit=1

Bug #14950 Updated: crash with __sleep() and __wakeup()

[artus]

 ID:   14950
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Analyzed
 Bug Type: Session related
 Operating System: Debian SID
 PHP Version:  4.2.0-dev
 New Comment:

I have the same problem running apache 2.0.35 and php 4.2 RC3 under
Win2K ...


Previous Comments:


[2002-04-03 11:06:21] [EMAIL PROTECTED]

I just tested. It does not work.



[2002-03-22 05:30:46] [EMAIL PROTECTED]

Could you try CVS version to see if this bug is fixed?



[2002-03-06 03:25:20] [EMAIL PROTECTED]

Version update

I just take a look at what is going on, __sleep and __wakeup is messed
badly. It does not work at all and even crashes...




[2002-02-03 19:44:04] [EMAIL PROTECTED]

This will be next my target to fix :)



[2002-01-09 10:38:21] [EMAIL PROTECTED]

Forgot to tell : asking for .phps will show you the source in the
/test/session/ directory.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14950

-- 
Edit this bug report at http://bugs.php.net/?id=14950&edit=1

Bug #15759 Updated: pgsql.c void value not ignored as it ought to be

[yohgaki]

 ID:   15759
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Solaris 2.8
 PHP Version:  4.1.1
 New Comment:

Pieter,

Sorry, it does not make sense to support PostgreSQL 6.3.x for PHP 4.1.x
or later... Even 6.5.3 has critical bug, AFAIK. I strongly suggest you
to upgrade to 7.0.3, at least.

If you send patch against CVS version, I might apply if it does not
anything bad to newer releases.

--
Yasuo




Previous Comments:


[2002-02-28 04:44:03] [EMAIL PROTECTED]

My PostgreSQL is indeed rather old (version 6.3.2)
but so far it always worked well.

A newer version (7.2 latest) will probably force me
to setup a new database of users etc...

Would there be another work arround ?

Pieter



[2002-02-28 03:28:27] [EMAIL PROTECTED]

You have something wrong in your libpq.

The line contains something like 
result = PQputline(.);
and PQputline's prototype is 
int PQputline(PGconn *conn, const char *string);

What is your libpq version? (PostgreSQL version?)



[2002-02-27 05:25:22] [EMAIL PROTECTED]

Downloaded Apache_1.3.23, PHP_4.1.1 (=matest versions)
Env. vars set:
INFORMDIR=/home/informix2000
PATH=/home/informix2000/bin:$PATH
LD_LIBRARY_PATH=/home/informix2000/lib/esql:$LD_LIBRARY_PATH
LIBRARY_PATH=/home/informix2000/lib/esql:$LIBRARY_PATH
SQLEXEC=
export INFORMIXDIR PATH LD_LIBRARY_PATH LIBRARY_PATH SQLEXEC

Unpacked apache-1.3.23, did a 
# ./configure --prefix=/usr/local/apache_1323

Unpacked php_4.1.1, did a
# ./configure
--with-apache=/home/wins/cosslocal/src/other/apache_1.3.23 \
   --with=pgsql \
   --with-informix=/home/informix2000 \
   --enable-yp

(we have PGSQL in /usr/local/pgsql and INFORMIX2000
up and running)

then did a
# make
...
at the gcc compile of pgsql.c I get:
pgsql.c: In function 'zif_pg_put_line':
pgsql.c:849: void value not ignored as it ought to be
make[3]: *** [pgsql.lo] Error 1
...

I didn't have that error with our previous
apache_1.3.14 and PHP4.0.4pl1 compilation (with the
same PGSQL and INFORMIX2000)

At line 849 in pgsql.c I don't find zif_pg_put_line,
substring 'zif' is nowhere in pgsql.c ...

Pieter






-- 
Edit this bug report at http://bugs.php.net/?id=15759&edit=1

Bug #16589 Updated: php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error

[misiek]

 ID:   16589
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Zlib Related
 Operating System: PLD Linux
-PHP Version:  4.1.2
+PHP Version:  4.2.0RC3
 New Comment:

Fix version.


Previous Comments:


[2002-04-13 11:20:41] [EMAIL PROTECTED]

php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error:

#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) bt
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
#1  0x00839856 in php_log_err (
log_message=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"..., tsrm_ls=0x1775ff0) at
main.c:324
#2  0x00839d57 in php_error_cb (type=32, error_filename=0x8e8f2b
"Unknown", error_lineno=0, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n", 
args=0xb758 "wâ|") at main.c:459
#3  0x0082c917 in zend_error (type=32, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled
with module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with
module API=%d, debug=%d, thread-safety=%d\nThese options need to
match\n") at zend.c:682
#4  0x0088cd51 in php_dl (file=0x1d46ff0, type=1,
return_value=0xb7c0, tsrm_ls=0x1775ff0) at dl.c:202
#5  0x0083f5c3 in php_load_function_extension_cb (arg=0x1d46ff0,
tsrm_ls=0x1775ff0) at php_ini.c:188
#6  0x008244cd in zend_llist_apply (l=0x915f3c, func=0x83f58a
, tsrm_ls=0x1775ff0)
at zend_llist.c:186
#7  0x0083faa4 in php_ini_delayed_modules_startup (tsrm_ls=0x1775ff0)
at php_ini.c:313
#8  0x0083ba4b in php_module_startup (sf=0x77a020) at main.c:1001
#9  0x00778ca3 in php_apache_server_startup (pconf=0x4d4010,
plog=0x513010, ptemp=0x516010, s=0x4fe118)
at sapi_apache2.c:435
#10 0x080681e5 in ap_run_post_config (pconf=0x4d4010, plog=0x513010,
ptemp=0x516010, s=0x4fe118) at config.c:130
#11 0x0806e545 in main (argc=2, argv=0xb9e4) at main.c:569
#12 0x003c0418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) print ctx
$8 = (struct php_struct *) 0x0
(gdb) 





-- 
Edit this bug report at http://bugs.php.net/?id=16589&edit=1

Bug #16589: php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error

[misiek]

From: [EMAIL PROTECTED]
Operating system: PLD Linux
PHP version:  4.1.2
PHP Bug Type: Zlib Related
Bug description:  php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error

php 4.2.0rc3+apache2.0.35+zlib crashes while displaying error:

#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) bt
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
#1  0x00839856 in php_log_err (
log_message=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"..., tsrm_ls=0x1775ff0) at main.c:324
#2  0x00839d57 in php_error_cb (type=32, error_filename=0x8e8f2b
"Unknown", error_lineno=0, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled with
module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with module
API=%d, debug=%d, thread-safety=%d\nThese options need to match\n", 
args=0xb758 "wâ|") at main.c:459
#3  0x0082c917 in zend_error (type=32, 
format=0x8f3de0 "%s: Unable to initialize module\nModule compiled with
module API=%d, debug=%d, thread-safety=%d\nPHPcompiled with module
API=%d, debug=%d, thread-safety=%d\nThese options need to match\n") at
zend.c:682
#4  0x0088cd51 in php_dl (file=0x1d46ff0, type=1, return_value=0xb7c0,
tsrm_ls=0x1775ff0) at dl.c:202
#5  0x0083f5c3 in php_load_function_extension_cb (arg=0x1d46ff0,
tsrm_ls=0x1775ff0) at php_ini.c:188
#6  0x008244cd in zend_llist_apply (l=0x915f3c, func=0x83f58a
, tsrm_ls=0x1775ff0)
at zend_llist.c:186
#7  0x0083faa4 in php_ini_delayed_modules_startup (tsrm_ls=0x1775ff0) at
php_ini.c:313
#8  0x0083ba4b in php_module_startup (sf=0x77a020) at main.c:1001
#9  0x00778ca3 in php_apache_server_startup (pconf=0x4d4010,
plog=0x513010, ptemp=0x516010, s=0x4fe118)
at sapi_apache2.c:435
#10 0x080681e5 in ap_run_post_config (pconf=0x4d4010, plog=0x513010,
ptemp=0x516010, s=0x4fe118) at config.c:130
#11 0x0806e545 in main (argc=2, argv=0xb9e4) at main.c:569
#12 0x003c0418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0  0x007783eb in php_apache_sapi_log_message (
msg=0xbfffeec0 "PHP Warning:  zlib: Unable to initialize
module\nModule compiled with module API=20010901, debug=1,
thread-safety=1\nPHPcompiled with module API=20010901, debug=0,
thread-safety=1\nThese options need"...)
at sapi_apache2.c:214
214 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO |
APLOG_STARTUP, 0, ctx->r->server, "%s", msg);
(gdb) print ctx
$8 = (struct php_struct *) 0x0
(gdb) 

-- 
Edit bug report at http://bugs.php.net/?id=16589&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16589&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16589&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16589&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16589&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16589&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16589&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16589&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16589&r=submittedtwice

Bug #16570 Updated: error control operator and set_error_handler()

[alberty]

 ID:   16570
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: i686-pc-linux-gnu
 PHP Version:  4.0CVS-2002-04-12
 New Comment:

sorry, my mistake.


Previous Comments:


[2002-04-12 17:08:33] [EMAIL PROTECTED]

Not a bug. If @ is used, error_reporting is set to 0.
You need to take care of it yourself in your error handler
function if you don't want to show errors in that case.

This is done this way to let users have as much control
as possible in their own error handlers.

And it is documented here:

http://www.php.net/manual/en/function.set-error-handler.php

--Jani




[2002-04-12 12:49:16] [EMAIL PROTECTED]

Hi,

the @ Error Control Operator doesnt suppress warnings
(e.g.:E_WARNING),
if an own error handler is declared.

the follow code snip demonstrate the problem:

in $errfileline $errline";
}

$old_error_handler = set_error_handler('error_handler');

$dbconnect=@mysql_pconnect('foobar-server', 'bart', 'simson');
?>

I think this is a bug, because this behavior is not documented.


Regards,

Steve




-- 
Edit this bug report at http://bugs.php.net/?id=16570&edit=1

Bug #16506 Updated: Oci Lob missing in Oracle 8.0.5 oci.dll

[thies]

 ID:   16506
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Win32
 PHP Version:  4.1.2
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php




Previous Comments:


[2002-04-09 04:33:51] [EMAIL PROTECTED]

Hi, I noticed that in the bin release of php_oci8.dll some imported
functions from oci.dll are missing when you use oracle 8.0.5 (OCI Lob
functions): this prevents the extension to be loaded from the web
server. I had to recompile the extension putting #undef
HAVE_OCI8_TEMP_LOB somewhere in php_oci.h. The problem is not present
(of course) when I use the lib with oracle 8.1.7 client. Maybe oracle
8.0.5 client is not used at all by much people... but you may
distribute two versions of the lib or put a note somewhere...

regards,
andrea




-- 
Edit this bug report at http://bugs.php.net/?id=16506&edit=1

Bug #15390 Updated: Persistent OCI8 Connections Get Poisoned

[thies]

 ID:   15390
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: RedHat 6.2
 PHP Version:  4.0.6
 New Comment:

hack:
change your tnsnames.ora to include a failover to the same db.
PROD=(
DESCRIPTION=(
ADDRESS=(PROTOCOL=TCP)(Host=127.0.0.1)(Port=1521))
   
(CONNECT_DATA=(SID=PROD)(failover_mode=(backup=PROD)(type=session)(method=basic)(retry=100)(delay=60)))

)

this will make the Net8 client to reconnect automagically



Previous Comments:


[2002-04-09 11:30:29] [EMAIL PROTECTED]

Same problem exists under:
RedHat 7.2
PHP 4.1.2 (--with-oci8)
Oracle8i 8.1.5



[2002-02-05 12:59:47] [EMAIL PROTECTED]

I have PHP 4.0.6 compiled as an Apache 1.3.20 module with OCI8 and
MySQL on RedHat 6.2.  I use persistent connections with OCI8 to avoid
the costly connection construction for Oracle for each request. 
However, I notice that these persistent connections get "poisoned"
under certain
circumstances.  What I mean by this is this:

Since each persistent connection stays with it's corresponding Apache
process, if the database happens to be down when a request comes in,
the persistent connection that is used throws an ORA-03113.  However,
even when the database comes back, the persistent connection still
thinks the database is down somehow, and will continue to throw the
ORA-03113 error.  As a result, if a request happens to hit the poisoned
Apache process, it appears the database is down.  If a request hits
another Apache process, all is OK.

So far, the only way I've seen to deal this is to restart Apache, and
have the persistent connections build up again.  Obviously, this is not
a good thing, and if database connectivity is lost in any form, the
persistent connections get poisoned again, and the cycle begins.

Now as this might not be a bug per se, I would think that persistent
connections should at least check that they aren't corrupted in some
way; or 'freshen' themselves.  Although I haven't tested it fully, I
have never seen this behavior with persistent MySQL connections.

Please contact me for any further details or clarification if needed.

Thank you,

Hans




-- 
Edit this bug report at http://bugs.php.net/?id=15390&edit=1

Bug #16502 Updated: OCIPLogon does not reconnect to restarted Database

[thies]

 ID:   16502
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: OCI8 related
 Operating System: RedHat 7.2
 PHP Version:  4.1.2
 New Comment:

hack:
change your tnsnames.ora to include a failover to the same db.
PROD=(
DESCRIPTION=(
ADDRESS=(PROTOCOL=TCP)(Host=127.0.0.1)(Port=1521))
   
(CONNECT_DATA=(SID=PROD)(failover_mode=(backup=PROD)(type=session)(method=basic)(retry=100)(delay=60)))

)

this will make the Net8 client to reconnect automagically



Previous Comments:


[2002-04-13 09:20:49] [EMAIL PROTECTED]

hack:
change your tnsnames.ora to include a failover to the same db.
PROD=(
DESCRIPTION=(
ADDRESS=(PROTOCOL=TCP)(Host=127.0.0.1)(Port=1521))
   
(CONNECT_DATA=(SID=PROD)(failover_mode=(backup=PROD)(type=session)(method=basic)(retry=100)(delay=60)))

)

this will make the Net8 client to reconnect automagically




[2002-04-08 23:16:52] [EMAIL PROTECTED]

Hello,

I have an issue between PHP and Oracle. As soon as I have to restart
database I have to do same for Apache. If I will not do that my session
will retrieve error message about "end-of-file coonection". I agree
that some of child processes in Apache can be in this status. But I
guess, that it is possible to track that OCIPLogon tries to connect to
DB through dead connection. That can trigger whole "connection process"
to run again. It is better than wait for administrator to restart whole
web server. I prefer OCIPLogon for small SELECT's because of
performance issue.

I tried to solve this issue with   apache_child_terminate() but
received message that it is disabled somehow (I even have no idea how
to enable it)

My environment is:
RedHat 6.1 / 7.2
Apache 1.3.23
PHP 4.1.2  (--with-oci8)
Oracle 8.1.5 client
remote Oracle7 and Oracle8.1.5 databases


Thanks for any advise,
Boris
[EMAIL PROTECTED]




-- 
Edit this bug report at http://bugs.php.net/?id=16502&edit=1

Bug #16502 Updated: OCIPLogon does not reconnect to restarted Database

[thies]

 ID:   16502
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: RedHat 7.2
 PHP Version:  4.1.2
 New Comment:

hack:
change your tnsnames.ora to include a failover to the same db.
PROD=(
DESCRIPTION=(
ADDRESS=(PROTOCOL=TCP)(Host=127.0.0.1)(Port=1521))
   
(CONNECT_DATA=(SID=PROD)(failover_mode=(backup=PROD)(type=session)(method=basic)(retry=100)(delay=60)))

)

this will make the Net8 client to reconnect automagically



Previous Comments:


[2002-04-08 23:16:52] [EMAIL PROTECTED]

Hello,

I have an issue between PHP and Oracle. As soon as I have to restart
database I have to do same for Apache. If I will not do that my session
will retrieve error message about "end-of-file coonection". I agree
that some of child processes in Apache can be in this status. But I
guess, that it is possible to track that OCIPLogon tries to connect to
DB through dead connection. That can trigger whole "connection process"
to run again. It is better than wait for administrator to restart whole
web server. I prefer OCIPLogon for small SELECT's because of
performance issue.

I tried to solve this issue with   apache_child_terminate() but
received message that it is disabled somehow (I even have no idea how
to enable it)

My environment is:
RedHat 6.1 / 7.2
Apache 1.3.23
PHP 4.1.2  (--with-oci8)
Oracle 8.1.5 client
remote Oracle7 and Oracle8.1.5 databases


Thanks for any advise,
Boris
[EMAIL PROTECTED]




-- 
Edit this bug report at http://bugs.php.net/?id=16502&edit=1

Bug #16183 Updated: Problem with multiple sessions on a persistent connection

[thies]

 ID:   16183
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: RedHat 7.2
 PHP Version:  4.1.2
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2002-03-21 08:32:30] [EMAIL PROTECTED]

This is related to the same script as bug#16181, but the OCI8 functions
used are not the same (two OCIPLogon for both 'user1' and 'user2'
instead of one OCIPLogon for 'user1' and an OCINLogon for 'user2'), and
more importantly the malfunction observed is quite different.
IMHO it may be worth investigating both.



[2002-03-21 06:17:08] [EMAIL PROTECTED]

Please do not open two bugreports about the same problem.



[2002-03-20 07:00:14] [EMAIL PROTECTED]

Environment is Linux RedHat 7.2, Apache 1.3.23, PHP 4.1.2 DSO with OCI8
(8.1.7.0) and several other extensions; the Oracle database (8.1.7.3)
is on a Win2k server.

This bug report stems from an attempt to overcome the problem described
in bug#16181.

I have a script implementing session handling against Oracle that's
included at the top of each and every page of an application.

I cannot share the transaction context with the application but want to
create a single, persistent connection to the DB, so I use
OCIPlogon('user1', 'pwd1', 'alias') in the included file, while the
application connects with OCIPlogon('user2', 'pwd2', 'alias').

If I query the v$session table for username,process,status I observe
two sessions per process, which is expected; the number of processes is
equal to the active Apache processes, which is also expected since I am
currently not using the Oracle multithreaded server (MTS).

This appears to work 99.9% of the time, even though I am not 100% sure
I am getting different transaction contexts with the OCIPLogons (the
manual could be clearer on these fine points).

Problem is that randomly, when the session handling code is writing
down the updated session variables at script end, Oracle responds with
ORA-00942: table or view does not exist.

I traced the requests on the server side and discovered that, while the
request is correctly formed it is associated with 'user2' instead of
'user1'; this explains the error since 'user2' is not granted access to
the session table.

I believe this is a bug, since there is no evidence of transaction
context problems and maybe the OCI8 extension is just selecting the
wrong user from its internal session cache.




-- 
Edit this bug report at http://bugs.php.net/?id=16183&edit=1

Bug #16181 Updated: Persistent OCINLogon session-handles

[thies]

 ID:   16181
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: RedHat 7.2
 PHP Version:  4.1.2
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2002-03-20 06:22:44] [EMAIL PROTECTED]

Environment is Linux RedHat 7.2, Apache 1.3.23, PHP 4.1.2 DSO with OCI8
(8.1.7.0) and several other extensions; the Oracle database (8.1.7.3)
is on a Win2k server. 

I have a script implementing session handling against Oracle that's
included at the top of each and every page of an application.

I cannot share the transaction context with the application but want to
create a single, persistent connection to the DB, so I use
OCIPlogon('user1', 'pwd1', 'alias') in the included file, while the
application connects with OCINlogon('user2', 'pwd2', 'alias').

If I query the v$session table for username,process,status I observe an
ever growing number of INACTIVE 'user2' sessions for each process, and
eventually Oracle complains for too many sessions.

I read "Making efficient use of Oracle8i thru Apache and PHP 4"
thoroughly and believed I was following its advice:

"...so if you need to isolate transactions on one page you would use
OCILogon() or OCIPLogon() for the "main" connection and create an
additional connection using OCINLogon(). the OCINLogon() connection
would be handled thru the same server-handle as the other connection
but would have it's own session-handle. side-note: the session-handle
created by OCINLogon() will always be freed at the end of the
script..."

Looks like the above is not true when using OCIPLogon, but I think it
should be.




-- 
Edit this bug report at http://bugs.php.net/?id=16181&edit=1

Bug #15577 Updated: "failed to rollback outstanding transactions!" Oracle connection error

[thies]

 ID:   15577
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Solaris
 PHP Version:  4.1.1
 New Comment:

please send me a short fully self-contained testcase.



Previous Comments:


[2002-02-15 15:14:03] [EMAIL PROTECTED]

I have a function: 
-
function SQLreturn($sql){
$OC = @OCINLogon($this->user,$this->pass,$this->string);
if($OC){
$parsed = OCIParse($OC,$sql);
OCIExecute($parsed);
OCIFetchInto($parsed, &$rows,OCI_ASSOC);
OCIFreeStatement($parsed);
OCILogOff($OC);
//return the array
//print_r($rows);
return $rows;
}else{
echo "No SQL connect: return";
}
}


that appears to cause some trouble...I'm not sure why either. Other
database connections work fine on this same server, but this one keeps
giving messages like: 

Warning: failed to rollback outstanding transactions!: Error while
trying to retrieve text for error ORA-03113 in
/export/home1/catalog/domainadmin/index.php on line 97

Warning: _oci_close_session: OCISessionEnd: Error while trying to
retrieve text for error ORA-12545 in
/export/home1/catalog/domainadmin/index.php on line 97

Has anyone else encountered this one? If so, any idea how to fix it?
thanks,
-chris




-- 
Edit this bug report at http://bugs.php.net/?id=15577&edit=1

Bug #15499 Updated: Apache crashes with Segmentation fault

[thies]

 ID:   15499
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

please try to send me a short _selfcontained_ script that reproduces
that problem when hitting apache with ab.

i'm very busy right now. please contact me directly - money can raise
the priority of this problem on my TODO list.



Previous Comments:


[2002-03-28 04:08:47] [EMAIL PROTECTED]

Now I upgradet from Oracle 8.1.7 to Oracle 8.1.7.3, recompiled
 php and apache (4.1.2) with no effect. The crash still exists. 

It seems that nobody of the php-team feels responsible for improvements
in the oci8-module!?



[2002-03-12 08:48:10] [EMAIL PROTECTED]

We will pay for the support if the bug can be fixed from  one of the
php-developers.

I think the maintainer of this module will find the bug more quickly.



[2002-03-12 08:30:00] [EMAIL PROTECTED]

I already tried the latest version from cvs
/* $Id: oci8.c,v 1.168 2002/02/10 12:41:52 thies Exp $ */
and 
/* $Id: php_oci8.h,v 1.23 2002/02/10 12:41:52 thies Exp $ */

with the same effect



[2002-03-12 08:25:19] [EMAIL PROTECTED]

Can you possible try a snapshot from snaps.php.net?

Derick



[2002-03-12 08:24:46] [EMAIL PROTECTED]

You can try to fix it yourself...
If you've fixed it, please post a diff here or send it to
[EMAIL PROTECTED]



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15499

-- 
Edit this bug report at http://bugs.php.net/?id=15499&edit=1

Bug #16583 Updated: php 4.2.0RC3 always crashes apache 2.0.35 server at start

[misiek]

 ID:   16583
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Reproducible crash
+Bug Type: Apache2 related
 Operating System: PLD Linux
-PHP Version:  4.1.2
+PHP Version:  4.2.0RC3
 New Comment:

After running httpd via ElectricFence I got different backtrace...
problaby there is some memory corruption(?).

#0  0x007f0e68 in ts_resource_ex (id=1, th_id=0x0) at TSRM.c:307
307 TSRM_ERROR((TSRM_ERROR_LEVEL_INFO,
"Fetching resource id %d for current thread %d", id, (long)
thread_resources->thread_id));
(gdb) 
(gdb) bt
#0  0x007f0e68 in ts_resource_ex (id=1, th_id=0x0) at TSRM.c:307
#1  0x0075831e in php_module_startup (sf=0x55b020) at main.c:856
#2  0x00559ca3 in php_apache_server_startup (pconf=0x4d5010,
plog=0x514010, ptemp=0xa91010, s=0x4d6d60)
at sapi_apache2.c:435
#3  0x080681e5 in ap_run_post_config (pconf=0x4d5010, plog=0x514010,
ptemp=0xa91010, s=0x4d6d60) at config.c:130
#4  0x0806e7a5 in main (argc=2, argv=0xb9c4) at main.c:611
#5  0x003c0418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0  0x007f0e68 in ts_resource_ex (id=1, th_id=0x0) at TSRM.c:307
307 TSRM_ERROR((TSRM_ERROR_LEVEL_INFO,
"Fetching resource id %d for current thread %d", id, (long)
thread_resources->thread_id));
(gdb) print thread_resources  
$1 = (struct _tsrm_tls_entry *) 0xaa
(gdb) print *thread_resources
Cannot access memory at address 0xaa
(gdb) print tls_key
$2 = 1

For now I did:
thread_resources = pthread_getspecific(tls_key);
+thread_resources = NULL;
#elif defined(TSRM_ST)


and wget -S myserver tells me:
Server: Apache/2.0.35 (Unix) PHP/4.2.0RC3

And it works
http://misie.k.pl/phptest.php

Now I'm waiting for official fix instead of mine ugly workaround.


Previous Comments:


[2002-04-13 05:15:00] [EMAIL PROTECTED]

I also added patch from php cvs (after rc3):
--- php4/sapi/apache2filter/sapi_apache2.c  11 Apr 2002 20:34:31
-  1.61.2.8
+++ php4/sapi/apache2filter/sapi_apache2.c  12 Apr 2002 22:26:28
-  1.61.2.9
(modifies safe_free() define)

And now:
#0  0x0039605d in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) where
#0  0x0039605d in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x0062f646 in tsrm_mutex_lock (mutexp=0x0) at TSRM.c:492
#2  0x0062f2f8 in ts_resource_ex (id=0, th_id=0x0) at TSRM.c:318
#3  0x00568400 in _zend_bailout (filename=0x644f84 "zend_hash.c",
lineno=98) at zend.c:522
#4  0x0056e0ba in _zend_is_inconsistent (ht=0x80dea70, file=0x644f84
"zend_hash.c", line=532) at zend_hash.c:98
#5  0x0056f919 in zend_hash_destroy (ht=0x80dea70) at zend_hash.c:532
#6  0x004fcfef in destroy_php_config () from
/usr/lib/apache/libphp4.so
#7  0x00168529 in apr_pool_cleanup_run () from /usr/lib/libapr.so.0
#8  0x00167d39 in apr_pool_clear () from /usr/lib/libapr.so.0
#9  0x0806e5af in main (argc=2, argv=0xba34) at main.c:579
#10 0x003bc418 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 2
#2  0x0062f2f8 in ts_resource_ex (id=0, th_id=0x0) at TSRM.c:318
318 tsrm_mutex_lock(tsmm_mutex);
(gdb) 
(gdb) print tsmm_mutex
$1 = (struct {...} *) 0x0
(gdb) l 
313 } else {
314 thread_id = *th_id;
315 }
316 
317 TSRM_ERROR((TSRM_ERROR_LEVEL_INFO, "Fetching resource
id %d for thread %ld", id, (long) thread_id));
318 tsrm_mutex_lock(tsmm_mutex);
319 
320 hash_value = THREAD_HASH_OF(thread_id,
tsrm_tls_table_size);
321 thread_resources = tsrm_tls_table[hash_value];
322



[2002-04-13 04:58:57] [EMAIL PROTECTED]

I wanted to test apache 2.0.35 with php 4.2.0RC3 on my Linux (2.4
kernel, 2.5.5 glibc, gcc 3.1 20020408 prerelease) unfortunately it
always crashes at start (backtrace below).

Anyway if fix is know then please let me know - I want to test it. I
also can provide more information if needed.

httpd -X
gdb /usr/sbin/httpd core 
...
#0  0x008332ce in ts_resource_ex (id=1, th_id=0x0) at TSRM.c:310
310
TSRM_SAFE_RETURN_RSRC(thread_resources->storage, id,
thread_resources->count);
(gdb) where
#0  0x008332ce in ts_resource_ex (id=1, th_id=0x0) at TSRM.c:310
#1  0x0077e56c in php_module_startup (sf=0x602020) at main.c:856
#2  0x00600cb5 in php_apache_server_startup (pconf=0x4d4010,
plog=0x513010, ptemp=0xad7010, s=0x4d5d60)
at sapi_apache2.c:433
#3  0x080681e5 in ap_run_post_config (pconf=0x4d4010, plog=0x513010,
ptemp=0xad7010, s=0x4d5d60) at config.c:130
#4  0x0806e7a5 in main (argc=2, argv=0xb9f4) at main.c:611
#5  0x003c0418 in __libc_start_main () from /lib/libc.so.6
$1 = (struct _tsrm_tls_entry *) 0xadcff0
(gdb) print *threa

Bug #15372 Updated: Apache hangs with PHP 4.1.1+oci8

[thies]

 ID:   15372
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Solaris 8
 PHP Version:  4.1.1
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php

ther seems to be some conflict using gcc to link the oracle-libs shred
into the php-apache chain. nothing i can do from here. maybe ask the
list.



Previous Comments:


[2002-02-05 16:36:01] [EMAIL PROTECTED]

I rebuilt PHP without any modules, and built the oci8 PHP module as a
dynamic module.  If I load oci8.so in a page using the dl() function,
the page works as expected.  
However, when I add oci8.so to the php.ini file like so:

extension=oci8.so

The webserver exibits the same behavior as I detailed before.



[2002-02-04 17:56:02] [EMAIL PROTECTED]

I built PHP 4.1.1 as a DSO module using GCC 2.95.3 (which was installed
from a sunfreeware package).  The Oracle client is version 8.1.7. 
ORACLE_HOME was properly set (I was able to connect to Oracle through
the sqlplus client).  The configure line was:

./configure --with-oci8

Configuration, compilation, and installation proceded without errors. 
Apache started without error (error_log set to debug level).

When attempting to access any URL on the server, the client recieves no
response and does not time out.  The request does not show up in the
access_log on the server.  The error_log shows nothing for about 10
minutes, then a series of the following errors appears:

sgslun: unable to create SOSD endpoint
sgslun: unable to create SOSD endpoint
[Mon Feb  4 16:42:35 2002] [error] (24)Too many open files: accept:
(client socket)


When PHP is built without oci8 support, Apache processes requests
normally.  PHP built with other modules (i.e. CURL, GD), and without
oci8 does not have this behavior.




-- 
Edit this bug report at http://bugs.php.net/?id=15372&edit=1

Bug #15274 Updated: Could not able to locate the OCI8 functions

[thies]

 ID:   15274
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Windows 2000
 PHP Version:  4.1.0
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php




Previous Comments:


[2002-01-30 07:04:03] [EMAIL PROTECTED]

Whenever i tried to install the 4.1.0 installshield version some files
and directories are missing (even php.ini also). But if i try to
install by unzipping the zip file version it is not recognizing changes
made in php.ini file.
thanking you,
Suresh.  



[2002-01-29 07:06:12] [EMAIL PROTECTED]

I am using Oracle 8.1.7 on Solaries mechine as Oracle Server. I am
contacting via oracle 8.1.6 client on Windows2000. My Apache web
server(version 3.1.22) on Windows2000 , PHP 4.1.0 as apache module. I
am seting LD_LIBRARY_PATH.

The Same thing is working fine with PHP4.0.4 on Apache 3.1.9 , Oracle
client and Server are same as above.  




-- 
Edit this bug report at http://bugs.php.net/?id=15274&edit=1

Bug #15198 Updated: unexpected error 'OCI8 Recursive call!'

[thies]

 ID:   15198
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Redhat Linux 6.1
 PHP Version:  4.1.1
 Assigned To:  thies
 New Comment:

No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".

if this itches you too badly you can just take out the exit(-1) call
from oci8.c and recompile. but it might kill your oracle MTS



Previous Comments:


[2002-02-28 13:31:40] [EMAIL PROTECTED]

I've also got a PHP application that suffered from the OCI8 Recursive
call! error after an upgrade to PHP 4.1.1.  It worked fine with PHP
4.0.x, but with 4.1.x it randomly chokes with that error.  There is
nothing special going on.  I'm not using bindings, I've just got
scripts that logon, parse, execute, insert, delete, logoff, etc. 
Because of this, I'm forced to stick with the 4.0.x tree.  I'd give you
more debugging information, but it is a deployed system and I don't
want to introduce the bugs into it.



[2002-02-05 05:07:25] [EMAIL PROTECTED]

are you sure that you are not hitting the time_limit?

reverting to 4.0.6 is not a smartthimg (tm) to do as a recursive oci
call might kill your oracle MTS (if you 
use it). that's the only reason this catch got implemented.

maybe useing ociinternaldebug(1) and sending me the output (and just
the output of the oci module) would 
help.




[2002-02-05 03:30:24] [EMAIL PROTECTED]

Well, I have investigated the situation a bit more:

I have a script which takes a long time (a maintenance script that runs
at night, using php cgi binary), so I have set set_time_limit(7200)
(which is two hours!)

In the script, there's a complex query that takes 3 minutes to run.
During this query, I get this OCI8 Recursive Call error and the script
fails, even though the time limit has not been reached yet. Is there
some internal timeout in the OCI calls? I now have to downgrade to
4.0.6 to prevent the problem.



[2002-01-25 10:40:07] [EMAIL PROTECTED]

this happens when an oci-call gets interrupted by a signal. this should
only happen in 2 stituations:

- you script hits max_execution_time (bad)

- you did an apachectrl restart instead of apachectrl graceful

the message "recursive call" is consitered a fatal-error and the apache
child that generated that message will be terminated by the php
oci-driveri. this is cause i've seen oracle MTS servers crashing when a
client tried to call the oci* stuff in a reentrant way. i currently
know no better way to save my "unbreakable" oracle from crashing;-)



[2002-01-25 10:39:26] [EMAIL PROTECTED]

this happens when an oci-call gets interrupted by a signal. this should
only happen in 2 stituations:

- you script hits max_execution_time (bad)

- you did an apachectrl restart instead of apachectrl graceful

the message "recursive call" is consitered a fatal-error and the apache
child that generated that message will be terminated by the php
oci-driveri. this is cause i've seen oracle MTS servers crashing when a
client tried to call the oci* stuff in a reentrant way. i currently
know no better way to save my "unbreakable" oracle from crashing;-)



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15198

-- 
Edit this bug report at http://bugs.php.net/?id=15198&edit=1

Bug #14800 Updated: Oracle connection probleme.

[thies]

 ID:   14800
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: windows2000 advance server
 PHP Version:  4.0.6
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".





Previous Comments:


[2002-01-02 09:53:12] [EMAIL PROTECTED]

When i would like to connect with Oracle 8i data base
  i receive this message.

Warning: OCISessionBegin: ORA-03113: end-of-file on communication
channel in e:\easyphp\www\exemplephp\oci_affiche.php on line 17

regards.






-- 
Edit this bug report at http://bugs.php.net/?id=14800&edit=1

Bug #14702 Updated: segfault in OCIFetchStatement with 1 or 2 chars CLOB

[thies]

 ID:   14702
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Linux 2.4
 PHP Version:  4.1.0
 New Comment:

please send me a short selfcontained testcase for this



Previous Comments:


[2001-12-27 07:55:59] [EMAIL PROTECTED]

(gdb) bt
#0  0x4056bc67 in ttci2u () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#1  0x40335490 in kpulbcr () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#2  0x40579002 in ttcdrv () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#3  0x40448855 in nioqwa () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#4  0x4035a9f2 in upirtrc () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#5  0x4033742d in kpurcsc () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#6  0x4032500c in kpulfrd () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#7  0x40344d7a in OCILobRead () from
/opt/oracle/Oracle8iR3/lib/libclntsh.so.8.0
#8  0x80781c6 in oci_loadlob (connection=0x81d7d0c, mydescr=0x81d7c24,
buffer=0xbfffd9b8, loblen=0xbfffd9bc)
at oci8.c:1860
#9  0x80771f4 in _oci_make_zval (value=0x81f206c, statement=0x81db77c,
column=0x81e641c, 
func=0x811d5ef "OCIFetchStatement", mode=8) at oci8.c:1242
#10 0x807bbc6 in zif_ocifetchstatement (ht=2, return_value=0x81e65e4,
this_ptr=0x0, return_value_used=1) at oci8.c:3970
#11 0x8103a55 in execute (op_array=0x81d15e4) at
/home/ch/php-4.1.0/Zend/zend_execute.c:1590
#12 0x80e5cc2 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:814
#13 0x8063921 in php_execute_script (primary_file=0xb9d0) at
main.c:1309
#14 0x8061bc4 in main (argc=2, argv=0xba74) at cgi_main.c:738
#15 0x407faf31 in __libc_start_main (main=0x80613d4 , argc=2,
ubp_av=0xba74, init=0x805f8d0 <_init>, 
fini=0x811843c <_fini>, rtld_fini=0x4000e274 <_dl_fini>,
stack_end=0xba6c) at ../sysdeps/generic/libc-start.c:129



[2001-12-27 05:52:55] [EMAIL PROTECTED]

Can you provide a backtrace?
(http://bugs.php.net/bugs-generating-backtrace.php)



[2001-12-26 13:28:59] [EMAIL PROTECTED]

php segfault with the following code :

$stmt = OCIParse($conn,"select myclob from I18N");
OCIExecute($stmt);
OCIFetchStatement($stmt,$results);

when myclob contains at least one row with one or two characters. work
fine when clob length = 0 or >= 3.
oracle and php use utf-8.

php : 4.1.0 and 4.0.6 on linux x86
oracle : 8.1.7.2 on sparc64





-- 
Edit this bug report at http://bugs.php.net/?id=14702&edit=1

Bug #14641 Updated: Unable to load php_oci8.dll .

[thies]

 ID:   14641
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: WIIN2000 SP2
 PHP Version:  4.1.0
 New Comment:

update your oracle client to >= 8.1



Previous Comments:


[2001-12-21 09:19:29] [EMAIL PROTECTED]

This problem started with PHP 4.0.6 , fix was to copy php_oci8.dll from
previous version . Now with PHP version 4.1.0 is this not possible .
Problem is related to Oracle client version and its dynamic library
OCI.DLL , all that reported problem with php_oci8.dll haved Oracle
8.0.5 client version . Can someone make php_oci8.dll "older client
safe" , we have on our site many Oracle applications , that can´t run
with newer versions of Oracle client .

Error message is "Input point from procedure OCILobCreateTemporary
can´t by found in dynamic library OCI.DLL" ( translated from czech 
).




-- 
Edit this bug report at http://bugs.php.net/?id=14641&edit=1

Bug #14278 Updated: % and / bug with INTEGERs!

[thies]

 ID:   14278
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Linux 2.2.19
 PHP Version:  4.0.6
 New Comment:

oops - closed to fast.

please send me a short _SELF_ contains script that shows the problem
(including the oci-calls)



Previous Comments:


[2002-04-13 09:00:59] [EMAIL PROTECTED]

all scalar values returned from PHP-OCI8 are strings.




[2002-04-09 18:12:39] [EMAIL PROTECTED]

recategorizing as an oci8 issue.



[2002-01-09 09:17:14] [EMAIL PROTECTED]

After some more investigation on this bug I noticed following:

I have an OCI insert statement executed with a 'RETURNING INTO' clause.
The value which is returned is a oracle DB entry of type NUMBER. I
expected to have the returned value in PHP to be a number as well. BUT
it is a string!

Some more output I produced in my script is:



The result (when the error occures):
106851 (type: string[6] - 1068514)

As you can see the value of the $num variable changes while automatic
type casting from string to int is executed.

The reason for the NEW (bigger) value is possibly a not null terminated
string value returned by the OCI interface.

My suggestion: While typecasting from string to int an extra check
should be done (e.g. detect if there is a null terminated string and if
not: terminate it).

Thanks for your patch!







[2001-12-20 12:48:09] [EMAIL PROTECTED]

No feedback. Closing.



[2001-11-29 15:42:41] [EMAIL PROTECTED]

E:\php>php -v
4.0.6

E:\php>php -q test.php
101110 22
3888 14
149 19
5 5
0 0
0 0
AAFTOW

No matter how many times I run this script I always get this.  Also
tested it on Linux (2.4), with PHP 4.2.0-dev and it works.

Please try a newer version and see if that fixes the problem you're
having. http://www.php.net/~zeev/php-4.1.0RC3.tar.gz or
http://snaps.php.net/php4-latest.tar.gz

-Chris




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14278

-- 
Edit this bug report at http://bugs.php.net/?id=14278&edit=1

Bug #14278 Updated: % and / bug with INTEGERs!

[thies]

 ID:   14278
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Linux 2.2.19
 PHP Version:  4.0.6
 New Comment:

all scalar values returned from PHP-OCI8 are strings.



Previous Comments:


[2002-04-09 18:12:39] [EMAIL PROTECTED]

recategorizing as an oci8 issue.



[2002-01-09 09:17:14] [EMAIL PROTECTED]

After some more investigation on this bug I noticed following:

I have an OCI insert statement executed with a 'RETURNING INTO' clause.
The value which is returned is a oracle DB entry of type NUMBER. I
expected to have the returned value in PHP to be a number as well. BUT
it is a string!

Some more output I produced in my script is:



The result (when the error occures):
106851 (type: string[6] - 1068514)

As you can see the value of the $num variable changes while automatic
type casting from string to int is executed.

The reason for the NEW (bigger) value is possibly a not null terminated
string value returned by the OCI interface.

My suggestion: While typecasting from string to int an extra check
should be done (e.g. detect if there is a null terminated string and if
not: terminate it).

Thanks for your patch!







[2001-12-20 12:48:09] [EMAIL PROTECTED]

No feedback. Closing.



[2001-11-29 15:42:41] [EMAIL PROTECTED]

E:\php>php -v
4.0.6

E:\php>php -q test.php
101110 22
3888 14
149 19
5 5
0 0
0 0
AAFTOW

No matter how many times I run this script I always get this.  Also
tested it on Linux (2.4), with PHP 4.2.0-dev and it works.

Please try a newer version and see if that fixes the problem you're
having. http://www.php.net/~zeev/php-4.1.0RC3.tar.gz or
http://snaps.php.net/php4-latest.tar.gz

-Chris




[2001-11-29 05:27:51] [EMAIL PROTECTED]

Sometimes (1 - 10 times a day) I get a strange error on one of my
production servers. See this function:

function MakeHash($num) {
  $ret = "";
  $ca = array();
  for ($i = 0; $i < 6; $i++) {
$c = $num % 26;
$ca[] = "$num $c";   
$ret = sprintf("%c", 65+$c).$ret;
$num = ($num-$c)/ 26;
  }
  // Send $ca array via email to me (removed)
  return $ret;
}

Sometimes calling this function with an INT it calculates wired
results... If that happens I mail the $ca array to myself and see what
it does:

101110 19  (MEANS: 101110 % 26 is 19!? That's wrong, it is 22)
3588 24   (MEANS 101110 / 26 is 3588, but it is 3888)
1495714 12...
57527 15
2212 2
85 7

What goes wrong? In the beginning the % result is wrong, and then the
division result is wrong too...  any suggestions!?

 /mike




-- 
Edit this bug report at http://bugs.php.net/?id=14278&edit=1

Bug #14193 Updated: I compile 4.2.0-dev well but when startup Apache not run

[thies]

 ID:   14193
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: tru64 v.5.1
 PHP Version:  4.0.6
 New Comment:

add 
 #undefine HAVE_OCI8_TEMP_LOB

to the top of oci8.c and recompile



Previous Comments:


[2001-11-23 04:09:58] [EMAIL PROTECTED]

NLS_LANG=SPANISH_SPAIN.WE8ISO8859P1
ORACLE_BASE=/u01/app/oracle
ORACLE_PATH=/u01/app/oracle/product/8.1.7/bin
LOGNAME=root
when I compile PHP/4.2.0-dev like DSO in tru64 v.5.1 with the
following variables of surroundings:


TEMPDIR=/u01/temp
ORACLE_SID=dborapre
GWSOURCE=telnet
ORACLE_OWNER=oracle
USER=root
ORACLE_DOC=/u01/app/oracle/product/8.1.7/doc
SHELL=/bin/ksh
ORACLE_TERM=vt220
ORA_NLS33=/u01/app/oracle/product/8.1.7/ocommon/nls/admin/data
HOME=/
LD_LIBRARY_PATH=/u01/app/oracle/product/8.1.7/lib
TERM=vt220
ORACLE_HOME=/u01/app/oracle/product/8.1.7


then I execute:

# ./configure --enable-ftp --with-gettext
--with-imap=/data/sebas/programs/imap-uw --with-oci8
--with-apxs=/usr/opt/IAE550/usr/internet/httpd/bin/apxs
--enable-dependency-tracking
#make
#make install

and when I start Apache:

Cannot load /usr/internet/httpd/libexec/libphp4.so into server: dlopen:
/usr/internet/httpd/libexec/libphp4.so: symbol "OCILobIsTemporary"
unresolved





-- 
Edit this bug report at http://bugs.php.net/?id=14193&edit=1

Bug #16580 Updated: Apache Hang On

[Juric]

 ID:   16580
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: win98
 PHP Version:  4.1.2
 New Comment:

ohhh.. I'm sorry... I've just tested with to diferent file size upload
and 3.4Mb file was succesfuly aploaded(very fast etc.. not like with
php4.1.2) but with file 8mb form was posted also very fast but
wariables did not recognized in receiver php file AND in Apache
Error.log file string:
Invalid method in request -7d225814ce0


Previous Comments:


[2002-04-13 08:53:19] [EMAIL PROTECTED]

With PHP 4.2.0RC3 everything works fine yet but form doesnt post all
variables where one of variable is ... but Apache
doesnt hang on



[2002-04-12 21:18:42] [EMAIL PROTECTED]

OK! I will try. Thank you
bytheway, that error could be connected with memory_limit?
I have just found that Memory_limit doesnt unrecognized on my windows
system...



[2002-04-12 19:10:57] [EMAIL PROTECTED]

Please test PHP 4.2.0RC3 from http://www.php.net/~derick/
(remember to replace php4ts.dll also!)




[2002-04-12 19:05:24] [EMAIL PROTECTED]

I use PHP 4.12 like a module of Apache 1322...
With php.ini all OK...
When I try to upload file larger than 5Mb than apears error:
FATAL:  erealloc():  Unable to allocate 5784001 bytes
And Apache hangs on...
The same problem was with older php and apache versions...
Help Please or give me the Link where is solve this problem
Thank You




-- 
Edit this bug report at http://bugs.php.net/?id=16580&edit=1

Bug #14024 Updated: can't do select on char, varchar2 etc. variables with oracle 9i

[thies]

 ID:   14024
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: linux;kernel-2.4.x
 PHP Version:  4.0.6
 New Comment:

set the oracle env vars _before_ you start apache. PutEnv will not
work.



Previous Comments:


[2001-11-12 02:30:03] [EMAIL PROTECTED]

After execution of the script bellow and any other script 
the php4 return:
Warning: OCIStmtExecute: ORA-03106: fatal two-task 
communication protocol error in 
/var/www/admin/sqlexecute.phtml on line 45
// line 45 is: ociexecute($stmt,OCI_DEFAULT);

putenv("ORACLE_SID=ORCL");
putenv("ORACLE_HOME=/home/oracle/u01/oracle/product/9.0.1");
putenv("LD_LIBRARY_PATH=/home/oracle/u01/oracle/product/9.0.1/lib");
$conn=OCIlogon ($usrname, $pass, "");
$Oerror=OCIError($conn);
$column_name[64];
if ($Oerror==false){
$stmt = ociparse($conn,$sqlstring);
ociexecute($stmt,OCI_DEFAULT);
$Oerror=OCIError($conn);
if ($Oerror==false){
$ncols = OCINumCols($stmt);
if ((int)$ncols==0){
OCIError($stmt);
OCIFreeStatement($stmt);
OCICommit($conn);
OCIlogoff($conn);
echo("Done.");
return;
}
echo("");
for ( $i = 1; $i <= $ncols; $i++ ) {
$column_name[$i]  = 
OCIColumnName($stmt,$i);
echo("$column_name[$i]");}
echo("");
while (ocifetch($stmt)){
for ( $i = 1; $i <= $ncols; $i++ ) {
   
echo("".ociresult($stmt,$column_name[$i])."");}
echo("");
}
echo("");
}
OCIError($stmt);
OCIFreeStatement($stmt);
OCICommit($conn);
OCIlogoff($conn);
}






-- 
Edit this bug report at http://bugs.php.net/?id=14024&edit=1

Bug #14013 Updated: ocibindbyname strips trailing spaces

[thies]

 ID:   14013
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Linux 2.2, Solaris 2.6
 PHP Version:  4.0.6
 New Comment:

try storing in a varchar2 firld, if you use CHAR oracle will trim
traing spaces.



Previous Comments:


[2001-11-11 06:49:19] [EMAIL PROTECTED]

Erm, yeah, that's supposed to be '$id = 666;'.



[2001-11-11 03:28:34] [EMAIL PROTECTED]

When inserting text using named binds, PHP will strip trailing spaces.
The same query on the same database using the same Oracle client
libraries. (All Oracle 8.1.6)

$db = ocilogon("u", "p", "sid");
$st = ociparse($db, "insert into test values (:id, :text)");
ocibindbyname($st, ":text", &$text, 2000);
ocibindbyname($st, ":id", &$id, 22);
$text = "  this line has spaces   ";
$node_id = 666;
ociexecute($st);





-- 
Edit this bug report at http://bugs.php.net/?id=14013&edit=1

Bug #13694 Updated: ocifetchstatement confuses PHP's memory management (or so it seems)

[thies]

 ID:   13694
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Solaris 8
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-10-17 09:42:06] [EMAIL PROTECTED]

This actually does not seem to happen specificially with
ocifetchstatement only; fetching the results with ocifetch and then
using ociresults to access the columns yields exactly the same
problem.




[2001-10-16 12:57:31] [EMAIL PROTECTED]

This actually does not seem to happen specificially with
ocifetchstatement only; fetching the results with ocifetch and then
using ociresults to access the columns yields exactly the same
problem.




[2001-10-16 12:10:21] [EMAIL PROTECTED]

Actually, no, or at least not to my knowledge. This is what I expected:



SQL> select uname, domain from bodevadm.email where pid = 275;

UNAME  DOMAIN
-- --
billgates  microsoft.com

SQL>


I also used this statement inside the php script for testing, but it
gave exactly the same error as the original one.




[2001-10-16 12:05:46] [EMAIL PROTECTED]

i'd rather guess you have some strange characters in the UNAME column?



[2001-10-16 11:46:52] [EMAIL PROTECTED]

I'm using PHP to access an Oracle database (version 8.0.5).
At one point, I execute ocifetchstatement() as follows:


$numrows = ocifetchstatement($stmt, $results);


where $stmt is a statement handle generated earlier, and $results is an
empty array. This seems to work fine, and sets $numrows to 1 (the
expected result); however, it is, later on, not possible use results -
for example, the line


$new_address = $results["UNAME"][0] . "@" . $results["DOMAIN"][0];


leaves $new_address as an empty string, which definitely cannot be
right - it should be, at the least, "@". Doing a var_dump($results)
right after the ocifetchstatement() call yields the following output:


array(2) {
  ["UNAME"]=>
  array(1) {
[0]=>
string(18) "


I am not an experienced PHP programmer - in fact, this is the first
time I use it at all -, but this definitely does not look right to me.
I'm not sure entirely what's happening, but my first guess would be
that ocifetchstatement() somehow messes up the internal representation
of $results.

FYI, here is how the statement handle $stmt was generated:


$stmt = ociparse($conn, "select uname, domain from bodevadm.email,
bodevadm.person where (bodevadm.email.pid = bodevadm.person.pid) and
(bodevadm.person.name like '%" . $new_nickname . "%')");


with $conn being the connection handle for the Oracle DB. The problem
is also present with other queries, though.

Any pointers in case this is a problem on my side rather than a php bug
would be greatly appreciated. Also, if you need any additional
information, please do not hesitate to contact me.

Thank you!





-- 
Edit this bug report at http://bugs.php.net/?id=13694&edit=1

Bug #13525 Updated: ORA-01005, ORA-12154 , ORA-12505

[thies]

 ID:   13525
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Linux( Suse 7 )
 PHP Version:  4.0.6
 New Comment:

don't use php PutEnv or apache SetEnv to set oracle env-vars. do it
BEFORE you start apache.



Previous Comments:


[2001-10-03 05:51:28] [EMAIL PROTECTED]

The folowing precedures have been tested when connecting to a HP UX
with Oracle 7.x using of couse the OCI8 as the client interface.

Add those lines to the web server config files or set and export those
ones before the web server starts.

SetEnv ORACLE_HOME /usr/local/oracle
SetEnv ORACLE_SID 
SetEnv LD_LIBRARY_PATH /usr/local/oracle/lib
SetEnv TNS_ADMIN /usr/local/oracle/tnsnames.ora
SetEnv TWO_TASK /usr/local/oracle/tnsnames.ora
SetEnv NLS_LANG  English_America.WE8ISO8859P1
SetEnv ORACLE_BASE /usr/local

When calling the OCILogon do this:

$db = "  (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST =server_ip_or_dns_name)(PORT =
1521))
(CONNECT_DATA= (SID = _sid_))
)";

The previous definition is a copy of the service definition that is
stored in the tnsnames.ora file.

Next, call the OCILogon function using the folowing format:

OCILogon("user/password","password", $db);

To avoid ORA-01005 error, set the NLS_LANG environment variable to
English_America.WE8ISO8859P1 ( some other values may work...but we have
found that this one works for us ).

To avoid ORA-12154 and ORA-12505, use the service definition as the
OCILogon third parameter.

It seams that there are errors in the OCILogin function in the
manual...please correct them.

I hope these lines can help.

Regards
Miguel Carvalho




-- 
Edit this bug report at http://bugs.php.net/?id=13525&edit=1

Bug #15665 Updated: readdir() crashes

[noemail]

 ID:   15665
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.4-STABLE
 PHP Version:  4.1.1
 New Comment:

forgon to tell you...
apache 1.3.22 and php4.1.1 (both from the ports collection)


Previous Comments:


[2002-04-13 08:54:30] [EMAIL PROTECTED]

I have the same problems with a script under freebsd4.5-release.
It just started crasching out of nothing. No change in the dirscancode,
no change on the server. Worked just fine before yesterday. The only
way to run the script now is to press the updatebutton in
internetexplorer several times quite quickly, it works when I do so (I
get about 5-6 httpds wotrking in the background).
This is so strange.



[2002-02-22 03:47:22] [EMAIL PROTECTED]

The option is --enable-debug, right?  --with-debug appeared to do
nothing.  When compiled with --enable-debug, the script did not crash. 
But it certainly crashes with a normal build without debugging.



[2002-02-21 19:30:43] [EMAIL PROTECTED]

I'll compile PHP from source with debugging and test tomorrow.  Can't
do it today since I just changed the code to exec find, and it already
processed today's files (is a webserver log processing helper script). 
 You're right, I know about the 0/false issue, but I was lazy since all
the filenames will always be fully qualified hostnames :)

I don't remember exactly how many times readdir() was being called
before it crashed, but probably somewhere between 100-200.  When it
first crashed, I noticed I had been calling that function a lot without
using closedir(), but after I added it and only called it once on a
single directory, it still crashed.



[2002-02-21 18:50:04] [EMAIL PROTECTED]

Can you enable --with-debug please and post a backtrace?

Btw, how often have you to call readdir() until it crashes?

Btw, your code won't work for directories containing files or dirs
naming like '0'; see the manual page and use 'while (false !== ($s =
readdir() ...'

Also, can you try the source relese itself please and not a/the port?



[2002-02-21 17:24:16] [EMAIL PROTECTED]

readdir() is consistently crashing PHP in one of my scripts. 
Unfortunately, I can't reproduce the problem with a small test script,
for some reason.  However, the function that is causing PHP to scrash
is shown below.  It is crashing after a number of readdir() calls:

function list_dir($name)
{
$d = opendir($name);
while ($s = readdir($d))
if (($s != ".") && ($s != ".."))
$a[] = $s;
closedir($d);
return isset($a) ? $a : false;
}

This is the CGI version, running from the command line.  A backtrace is
shown below:

(gdb) bt
#0  0x286ed20d in readdir_r () from /usr/lib/libc.so.4
#1  0x80dbd9b in php_if_readdir ()
#2  0x8146e04 in execute ()
#3  0x8146ffd in execute ()
#4  0x8146ffd in execute ()
#5  0x8146ffd in execute ()
#6  0x8129418 in zend_execute_scripts ()
#7  0x806e6be in php_execute_script ()
#8  0x806c8d0 in main ()
#9  0x806bcd3 in _start ()

I can provide more information if necessary.  PHP was compiled from
ports within the last week.





-- 
Edit this bug report at http://bugs.php.net/?id=15665&edit=1

Bug #13510 Updated: Web server crash when a connection is established with Oracle

[thies]

 ID:   13510
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: WinNT 4.0 SP6
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-10-02 08:31:17] [EMAIL PROTECTED]

The problem occurs on the following platform :

- Compaq Server Proliant ML330 with 256 Mo of Ram
- Windows NT 4.0 SP French
- Apache 1.3.20
- PHP 4.06 as DLL extension with extension OCI8
- IIS 4.0
- Oracle 8.1.6

When call to OCILogon, sometimes, we've got the error :
"ORA-12154: TNS : Symbolic address could not be resolved".

This error appears sometimes but not always.

It produces a crash on Apache or IIS.




-- 
Edit this bug report at http://bugs.php.net/?id=13510&edit=1

Bug #13450 Updated: Save method adds delimiters

[thies]

 ID:   13450
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Win 2000
 PHP Version:  4.0.6
 New Comment:

switch of magic_quotes


Previous Comments:


[2001-09-26 09:26:12] [EMAIL PROTECTED]

When using the lob->save method after posting data from a form php
string delimiters are inserted before the lob is written to the
database.

String delimiters are not added to lobs written using lob->savefile.
Surely this should be consistent between methods and, given that it is
likely that Oracle needs to interface to more than PHP it should be
removed from the save method. This doesn't seem to be documented
either.

EG:

original post data - Welcome to "Chez Moi"

becomes

Welcome to \"Chez Moi\"

submit again and it becomes

Welcome to \\\"Chez Moi\\\"






-- 
Edit this bug report at http://bugs.php.net/?id=13450&edit=1

Bug #13308 Updated: functon no foud in oci.dll

[thies]

 ID:   13308
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: windows nt
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-09-14 16:31:28] [EMAIL PROTECTED]

have installed sqlnet for oracle 8.0.5
and install php 4.0.6

run  phpinfo()
with exztension php_oci8.dll

error 
1.-the procedure entry point OCILobOpen could not be located in teh
dinamyc link library OCI.dll

2.- unable to load dynamic library "c:.../php_oci8.dll" the especified
procedure could not be found








-- 
Edit this bug report at http://bugs.php.net/?id=13308&edit=1

Bug #15665 Updated: readdir() crashes

[noemail]

 ID:   15665
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.4-STABLE
 PHP Version:  4.1.1
 New Comment:

I have the same problems with a script under freebsd4.5-release.
It just started crasching out of nothing. No change in the dirscancode,
no change on the server. Worked just fine before yesterday. The only
way to run the script now is to press the updatebutton in
internetexplorer several times quite quickly, it works when I do so (I
get about 5-6 httpds wotrking in the background).
This is so strange.


Previous Comments:


[2002-02-22 03:47:22] [EMAIL PROTECTED]

The option is --enable-debug, right?  --with-debug appeared to do
nothing.  When compiled with --enable-debug, the script did not crash. 
But it certainly crashes with a normal build without debugging.



[2002-02-21 19:30:43] [EMAIL PROTECTED]

I'll compile PHP from source with debugging and test tomorrow.  Can't
do it today since I just changed the code to exec find, and it already
processed today's files (is a webserver log processing helper script). 
 You're right, I know about the 0/false issue, but I was lazy since all
the filenames will always be fully qualified hostnames :)

I don't remember exactly how many times readdir() was being called
before it crashed, but probably somewhere between 100-200.  When it
first crashed, I noticed I had been calling that function a lot without
using closedir(), but after I added it and only called it once on a
single directory, it still crashed.



[2002-02-21 18:50:04] [EMAIL PROTECTED]

Can you enable --with-debug please and post a backtrace?

Btw, how often have you to call readdir() until it crashes?

Btw, your code won't work for directories containing files or dirs
naming like '0'; see the manual page and use 'while (false !== ($s =
readdir() ...'

Also, can you try the source relese itself please and not a/the port?



[2002-02-21 17:24:16] [EMAIL PROTECTED]

readdir() is consistently crashing PHP in one of my scripts. 
Unfortunately, I can't reproduce the problem with a small test script,
for some reason.  However, the function that is causing PHP to scrash
is shown below.  It is crashing after a number of readdir() calls:

function list_dir($name)
{
$d = opendir($name);
while ($s = readdir($d))
if (($s != ".") && ($s != ".."))
$a[] = $s;
closedir($d);
return isset($a) ? $a : false;
}

This is the CGI version, running from the command line.  A backtrace is
shown below:

(gdb) bt
#0  0x286ed20d in readdir_r () from /usr/lib/libc.so.4
#1  0x80dbd9b in php_if_readdir ()
#2  0x8146e04 in execute ()
#3  0x8146ffd in execute ()
#4  0x8146ffd in execute ()
#5  0x8146ffd in execute ()
#6  0x8129418 in zend_execute_scripts ()
#7  0x806e6be in php_execute_script ()
#8  0x806c8d0 in main ()
#9  0x806bcd3 in _start ()

I can provide more information if necessary.  PHP was compiled from
ports within the last week.





-- 
Edit this bug report at http://bugs.php.net/?id=15665&edit=1

Bug #13250 Updated: OCISessionBegin: ORA-03120: two-task conversion

[thies]

 ID:   13250
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Solaris 8 x86
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-09-11 11:31:50] [EMAIL PROTECTED]

When trying to connect to Oracle database from Solaris 8 on x86 station
to Solaris 8 on SPARC station, OCILogon fails with message:
ORA-03120: two-task conversion routine: integer overflow

It seems that this bug was already reported under
http://www.php.net/bugs.php?id=6456, but was close 'cause 
of missing feedback.

Code works fine when connecting to local database, also to remote
database on same platform x86, and it works also
fine to connect to "nrst.world" database from sqlplus and tnsping
works.

Solaris 8 (x86)
Apache 1.3.12
Oracle  8.1.5.0.0 
PHP 4.0.2

code:
this->conn = ocilogon("xxx","xxx","nrst.world");

error message:
OCIDebug: _oci_open_server new conn=0 dname=nrst.world

Warning: OCISessionBegin: ORA-03120: two-task conversion
routine: integer overflow in /opt/nrs/customerall.class on line 54
OCIDebug: _oci_open_session: FAILURE -> CLEANUP called
OCIDebug: START _oci_close_session: logging-off sess=0
OCIDebug: _oci_close_session: logging-off DEAD session
OCIDebug: oci_do_connect: FAILURE -> CLEANUP called
OCIDebug: START _oci_conn_list_dtor: id=0
OCIDebug: END _oci_conn_list_dtor: id=0







-- 
Edit this bug report at http://bugs.php.net/?id=13250&edit=1

Bug #12714 Updated: error on compiling with oracle8i

[thies]

 ID:   12714
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: SunOS  5.7
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-08-13 09:31:42] [EMAIL PROTECTED]

./configure --prefix=/local/home/php --with-apache=../apache_1.3.20
--with-oci8=../../oracle/app/oracle/product/8.0.3/ --enable-track-vars

make[3]: Entering directory `/local/home/Fontes/php-4.0.6/ext/oci8'
gcc  -I. -I/local/home/Fontes/php-4.0.6/ext/oci8
-I/local/home/Fontes/php-4.0.6/
main -I/local/home/Fontes/php-4.0.6
-I/local/home/Fontes/apache_1.3.20/src/inclu
de -I/local/home/Fontes/apache_1.3.20/src/os/unix
-I/local/home/Fontes/php-4.0.6
/Zend -I/local/home/Fontes/php-4.0.6/ext/mysql/libmysql
-I/local/home/oracle/app
/oracle/product/8.0.3/network/public
-I/local/home/oracle/app/oracle/product/8.0
.3/plsql/public -I/local/home/Fontes/php-4.0.6/ext/xml/expat/xmltok
-I/local/hom
e/Fontes/php-4.0.6/ext/xml/expat/xmlparse
-I/local/home/Fontes/php-4.0.6/TSRM  -
D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2  -c
oci8.c &
& touch oci8.lo
oci8.c: In function `php_if_ocicollgetelem':
oci8.c:4480: warning: passing arg 7 of `OCIDateToText' from
incompatible pointer  type
oci8.c: In function `php_if_ocicollassignelem':
oci8.c:4604: `dword' undeclared (first use in this function)
oci8.c:4604: (Each undeclared identifier is reported only once
oci8.c:4604: for each function it appears in.)
oci8.c:4604: parse error before `)'
oci8.c:4626: parse error before `)'
oci8.c:4657: parse error before `)'
make[3]: *** [oci8.lo] Error 1





-- 
Edit this bug report at http://bugs.php.net/?id=12714&edit=1

Bug #16580 Updated: Apache Hang On

[juric]

 ID:   16580
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: win98
 PHP Version:  4.1.2
 New Comment:

With PHP 4.2.0RC3 everything works fine yet but form doesnt post all
variables where one of variable is ... but Apache
doesnt hang on


Previous Comments:


[2002-04-12 21:18:42] [EMAIL PROTECTED]

OK! I will try. Thank you
bytheway, that error could be connected with memory_limit?
I have just found that Memory_limit doesnt unrecognized on my windows
system...



[2002-04-12 19:10:57] [EMAIL PROTECTED]

Please test PHP 4.2.0RC3 from http://www.php.net/~derick/
(remember to replace php4ts.dll also!)




[2002-04-12 19:05:24] [EMAIL PROTECTED]

I use PHP 4.12 like a module of Apache 1322...
With php.ini all OK...
When I try to upload file larger than 5Mb than apears error:
FATAL:  erealloc():  Unable to allocate 5784001 bytes
And Apache hangs on...
The same problem was with older php and apache versions...
Help Please or give me the Link where is solve this problem
Thank You




-- 
Edit this bug report at http://bugs.php.net/?id=16580&edit=1

Bug #12328 Updated: OCIStmtExecute: ORA-01460

[thies]

 ID:   12328
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  4.0.6
 New Comment:

see 

http://conf.php.net/oci2



Previous Comments:


[2001-07-24 02:51:44] [EMAIL PROTECTED]

On executing the code mentioned below, I get the following error:

"Warning: OCIStmtExecute: ORA-01460: unimplemented or unreasonable
conversion requested in /home/guest/chan/code/orafuncall.php on line
13"

The code is written in php4 on linux(suse) as;
  


Or can anybody help me on how to call oracle functions(procedure)
through php4.

from
-Chan




-- 
Edit this bug report at http://bugs.php.net/?id=12328&edit=1

Bug #13053 Updated: oci8 error, this kill oracle-prosseces in the oracle-instance.

[thies]

 ID:   13053
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: sun solaris 64 bits
 PHP Version:  4.0.6
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-08-30 05:34:29] [EMAIL PROTECTED]

Oci statement faild:

My error is: 
Warning: OCISessionBegin: ORA-24327: need explicit attach before
authenticating a user 

and 

Supplied argument is not a valid OCI8-Connection resource 

and

some rollback error as well.

regards

Jan Arve





-- 
Edit this bug report at http://bugs.php.net/?id=13053&edit=1

Bug #13030 Updated: Periodic inability to connect to database, ORA-24327

[thies]

 ID:   13030
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Solaris 7
 PHP Version:  4.0.6
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2001-08-29 09:44:35] [EMAIL PROTECTED]

Scripts that access oracle frequently fail to connect,
generating the error "OCISessionBegin: ORA-24327: need 
explicit attach before authenticating a user" when 
attempting OCIPLogon or OCINLogon. Accordin to the Oracle 
documentation, this message indicates that PHP attempted 
to open a connection on an invalid database handle.

Script:


\n";
   }
?>

Modules:

'./configure' '--prefix=/usr/local' 
'--with-apxs=/usr/local/apache/bin/apxs' 
'--with-config-file-path=/usr/local/apache/conf' 
'--disable-xml' '--enable-bcmath' '--enable-calendar' 
'--enable-ftp' '--enable-shared' '--enable-sigchild' 
'--enable-sysvshm' '--enable-sysvsem' '--enable-shmop' 
'--enable-trans-sid' '--enable-yp' '--disable-xslt' 
'--enable-discard-path' '--enable-gd-native-ttf' 
'--enable-ucd-snmp-hack' '--enable-magic-quotes' 
'--with-bz2=/home/jjmcin' 
'--with-db3=/home/jjmcin/tmp/php' 
'--with-dom=/home/jjmcin/tmp/php' 
'--with-gd=/home/jjmcin/tmp/php' 
'--with-png-dir=/home/jjmcin/tmp/php' 
'--with-jpeg-dir=/home/jjmcin/tmp/php' 
'--with-t1lib=/home/jjmcin/tmp/php' 
'--with-tiff-dir=/home/jjmcin/tmp/php' 
'--with-ttf=/home/jjmcin/tmp/php' 
'--with-freetype-dir=/home/jjmcin/tmp/php' 
'--with-xpm-dir=/home/jjmcin/tmp/php' 
'--with-iconv=/home/jjmcin/tmp/php' 
'--with-ldap=/home/jjmcin/tmp/php' 
'--with-mysql=/home/jjmcin' '--with-oci8' 
'--with-openssl=/home/jjmcin/tmp/php' 
'--with-pgsql=/home/jjmcin/tmp/php' 
'--with-snmp=/home/jjmcin/tmp/php/snmp' 
'--with-zlib-dir=/home/jjmcin/tmp/php' 
'--with-zlib=/home/jjmcin/tmp/php' 
'--with-sablot=/home/jjmcin/tmp/php' 
'--with-xslt-sablot=/home/jjmcin/tmp/php' 
'--with-expat-dir=/home/jjmcin/tmp/php' 
'--with-pdflib=/home/jjmcin/tmp/php' 
'--with-mcrypt=/home/jjmcin/tmp/php' 
'--with-mhash=/home/jjmcin/tmp/php' 
'--with-curl=/home/jjmcin/tmp/php' 
'--with-java=/opt/share/java1.2/jdk1.2.2'

All extensions are statically linked except Oracle.

Oracle version is 8.1.6, load on the oracle server is
fairly low and server is setup with default settings for
Solaris. Apache version is 1.3.14 running as user "nobody"
There is no observed connectivity problems using sqlplus
or other oracle utilities.

Environment variables are set properly. and queries work 
properly at least 40% of the time (just click the reload 
button in the browser).







-- 
Edit this bug report at http://bugs.php.net/?id=13030&edit=1

Bug #12973 Updated: Ocicolumnsize bug in NUMBER field

[thies]

 ID:   12973
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Hp-Ux11
 PHP Version:  4.0.6
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php

that's the way oracle returns this



Previous Comments:


[2001-08-27 07:38:46] [EMAIL PROTECTED]

When using 
$colsize[$i]=Ocicolumnsize($stmt,$i);
while $i is a loop var and $stmt is an sql statement
the return value for each field differ than NUMBER
is the actual correct size.In case of NUMBER type the return value is
somehow 22. 





-- 
Edit this bug report at http://bugs.php.net/?id=12973&edit=1

Bug #12847 Updated: php_oci8.dll dereferencing null-pointers

[thies]

 ID:   12847
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: NT 5 SP 1
-PHP Version:  4.0CVS-2001-08-19
+PHP Version:  4.0CVS-2001-08-1
 New Comment:

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".




Previous Comments:


[2001-08-19 16:31:56] [EMAIL PROTECTED]

I should've mentioned that the script contains just 





[2001-08-19 16:28:39] [EMAIL PROTECTED]

this is actually 4.0.7RC1
Server: Apache/1.3.20 (Win32) PHP/4.0.7RC1
php_oci8.dll linked against the 8.1.7 client libs

hitting the server with 
$ ./ab -n 5000 -c 3 -k http://212.24.143.100/other/info.php

produces more than a handful of these:

---
Apache.exe - Application Error
---
The instruction at "0x0070cb39" referenced memory at "0x". The
memory could not be "read".


Click on OK to terminate the program
Click on CANCEL to debug the program
---
OK   Cancel   
---

the errors go away with the extension disabled.




-- 
Edit this bug report at http://bugs.php.net/?id=12847&edit=1

Bug #12675 Updated: Link errors caused by new Oracle 8i LOB functions

[thies]

 ID:   12675
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Digital Unix V4.0F (Rev. 1229)
 PHP Version:  4.0.6
 New Comment:

just add 
#undefine HAVE_OCI8_TEMP_LOB
at the top of oci8.c and recompile



Previous Comments:


[2001-08-10 10:18:20] [EMAIL PROTECTED]

User Feedback (emailed)

./configure---with-apache=/afs/northstar.dartmouth.edu/uother/source/sys/apache/
apache_1.3.20 \
--with-oci8 \
--without-gdbm \
--with-xml \
--enable-wddx \
--disable-debug

The link errors were basic unresolved errors on:

OCILobOpen
OCILobClose
OCILobCreateTemp ?

My collegue who was doing this work said he found the unresolved
symbols
(routines) in an unreferenced oracle library. He tried to make this
work
by adding that library to the make file, but then he got all kinds of
other errors.

What version of Oracle do you have installed?

Thanks, David
---



[2001-08-09 17:15:42] [EMAIL PROTECTED]

I have the same version but I don't get any link errors.
What is your configure line and what exactly are the errors?

--Jani




[2001-08-09 13:40:24] [EMAIL PROTECTED]

When trying to link, the following dependancies were not satisfied by
our Oracle release (8.1.6):

OCILobOpen
OCILobClose
OCILobCreateTemp ?

Evidently these routines are in a different library, but if that
library is linked as well, many more errors are generated.

Perhaps the new LOB function additions will only build & work if you
have a later (or different) version of Oracle?




-- 
Edit this bug report at http://bugs.php.net/?id=12675&edit=1

Bug #12621 Updated: is always ORA-12699 Native service internal error

[thies]

 ID:  12621
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Closed
 Bug Type:OCI8 related
 PHP Version: 4.0.4
 New Comment:

something is wrong with your configuration (i'm not a windows guy so i
cannot help on this one) - this problem is not a bug in PHP.



Previous Comments:


[2001-08-07 10:51:10] [EMAIL PROTECTED]

I have installed NT4+PHP+ORACLE8.0.4+APACHE in my computer.
I want to access ORACLE server to another computer from web server.
It is ok to access ORACLE SERVER with PERL, but i cannot access using
PHP.
The first error is ora-12514 , but i change, change and change, now it
is always ORA-12699 Native service internal error .

$db="(DESCRIPTION=(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.1.4)(PORT = 1521))(CONNECT_DATA = (SID = ORCL)))";


Warning: _oci_open_server: ORA-12699:Native service internal error





-- 
Edit this bug report at http://bugs.php.net/?id=12621&edit=1

Bug #12514 Updated: OCILopOpen not found in oci.dll

[thies]

 ID:   12514
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: window NT
 PHP Version:  4.0.6
 New Comment:

the php binaries you have are linked against oracle-libs >= 8.1
please recompile php or install a newer oracle-client



Previous Comments:


[2001-08-01 09:30:30] [EMAIL PROTECTED]

First PC
NT 4.0 (server)
apache 1.3.20
php 4.0.6   ==> error
oracle 8.0.5

Error in french :p "Le point d'entrée de procédure OCILopOpen est
introuvable dans la bibliothèque de liaison dynamique oci.dll" And
after "unable to load dynamic library /extensions/php_oci8.dll" la
procédure spécifiée est introuvable"

Second PC
NT 4.0 (workstation)
apache 1.3.12   ===> ok
php 4.0.4
oracle 8.0.5




-- 
Edit this bug report at http://bugs.php.net/?id=12514&edit=1

Bug #12416 Updated: OleMainThreadWndName when using OCIFetchInto statement

[thies]

 ID:   12416
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Windows NT 4.0 Workstation
 PHP Version:  4.0.6
 New Comment:

please try a newer version of PHP and reopern if the problem is still
there.



Previous Comments:


[2001-07-27 03:48:37] [EMAIL PROTECTED]

Additional information

Correct Apache version: 1.3.12

The error.log of Apache displays the following line:
[Fri Jul 27 09:42:09 2001] [error] [client 10.19.2.9] Premature end of
script headers: f:/php/php.exe



[2001-07-27 03:21:05] [EMAIL PROTECTED]

OS: Windows NT 4.0 Workstation
Webserver: Apache 1.3
Database: Oracle 8.1.7
PHP Version: 4.0.6

I build two views in the database and use OCIFetchInto to collect the
data. The 1st view doesn't cause any problem. The 2nd view, almost
similar to the 1st one, causes a dialog to popup with the following
title:

OleMainThreadWndName: php.exe - Application Error

The instruction at "0x6021bc61" reference memory at "0x202020a4". The
memory could not be "read".

I tried to find a solution but couldn't find any.

Cheers

Pim 




-- 
Edit this bug report at http://bugs.php.net/?id=12416&edit=1

Bug #12401 Updated: "break;" doesn't seem to work propery

[thies]

 ID:   12401
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Linux Server 2.2.14-6.1.1
 PHP Version:  4.0.6
 New Comment:

i'm sure you found this out in the meantime



Previous Comments:


[2001-07-26 10:10:30] [EMAIL PROTECTED]

I'm not sure this is a bug.

Maybe one cannot just "break" out of an "if" or "else" block.

I have a html page that accepts a username and password and then calls
the code below.


https://192.168.1.3/easy2chat.html";);
exit;
} 

$db="";

$connection = OCILogon($username, $password, $db);
if ($connection == false){
   $msg = OCIError($connection)."";
}
else do {
// Looks like we need the "do..while()" so we can "break;" below!
$stmt = "select * from \"Person\"";
$cursor = OCIParse($connection, $stmt);
if (false == $cursor){
$msg = OCIError($cursor)."";
OCILogoff($connection);
break; 
}

$result = OCIExecute($cursor);
if (false == $result) {
$msg = OCIError($cursor)."";
OCILogoff($connection);
break;
}

echo "";
echo "

LegalEntityID
Person Name
Person Information
";

while (OCIFetchInto ($cursor, $values)){
$leID = $values[0];
$pName = $values[1];
$pInfo = $values[2];

echo "

$leID
$pName
$pInfo
";
}

echo "";

OCILogoff($connection);
} while (false);
?> 



Secret Area





https://192.168.1.3/easy2chat.html";);>






The problem is that if I use a user which doesn't have the
"Person" table in its schema the second "break;" (OCIExecute()) causes
the following error:


Warning: OCIStmtExecute: ORA-00942: table or view does not exist in
/home/httpd/html/sec_html/logon.php on line 25

Fatal error: Cannot break/continue 1 levels in
/home/httpd/html/sec_html/logon.php on line 29

My configure line was:
./configure  --without-mysql --with-oci8 --with-apache=../apache_1.3.20
--enable-track-vars --with-openssl

Best regards,
Andrei Lenkei




-- 
Edit this bug report at http://bugs.php.net/?id=12401&edit=1

Bug #12352 Updated: Unable to load dynamic library php_oci8.dll

[thies]

 ID:   12352
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Win 2000
 PHP Version:  4.0.6
 New Comment:

the php-binary you got is linked against oci-libs >= 8.1. either:
- install the oracle-client >= 8.1
- rebuild php on your system
 


Previous Comments:


[2001-07-24 18:05:47] [EMAIL PROTECTED]

I've got Oracle ver. 8.0.6 installed on my Win2000 and Apache 1.3.20
with PHP 4.0.6. There is error during starting Apache service. I've got
error message: can't find entry point of procedure OCILobOpen in
library OCI.dll ( sorry for translating error message but i've got
polish version of windows). Whhat should i do ?

extension=php_imap.dll
extension=php_oci8.dll

thank you ... 




-- 
Edit this bug report at http://bugs.php.net/?id=12352&edit=1

Bug #12269 Updated: session/oracle

[thies]

 ID:   12269
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: win2000
 PHP Version:  4.0.6


Previous Comments:


[2001-07-20 02:11:17] [EMAIL PROTECTED]

win2000+php4.06+apache1.3.20
1,"c:\php\php_oci8.dll" file Exists but systemp report cannot load
c:\php\php_oci8.dll module.
2,session cannot pass to another page
page1.php
 
 session_start();
 session_register("logon");
 Header("location:page2.php);
 
page2

session_start();
session_is_register("logon") return false; 
why?




-- 
Edit this bug report at http://bugs.php.net/?id=12269&edit=1

Bug #12260 Updated: Compile failure --with-oci8 and Oracle 8.0.4

[thies]

 ID:   12260
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Solaris 7 and 8
 PHP Version:  4.0.6
 New Comment:

please send me a .tar containing the header files for 8.0.4 


Previous Comments:


[2001-07-19 12:52:46] [EMAIL PROTECTED]

Compilation failes --with-oci8 and ORACLE_HOME pointing to oracle 8.0.4
installation. A typedef and define for symbol dword is only available
in oratypes.h of newer Oracle versions (checked with 8.0.5, 8.1.5 and
8.1.7) .

Solution: change dword to sb4 in ext/oci8/oci8.c, that's still matching
the oracle prototype (orl.h of oracle 8.1.7)

sword OCICollAssignElem(OCIEnv *env, OCIError *err, sb4 index, 
CONST dvoid *elem, 
CONST dvoid *elemind, OCIColl *coll);


gcc error:
oci8.c: In function `php_if_ocicollgetelem':
oci8.c:4480: warning: passing arg 7 of `OCIDateToText' from
incompatible pointer type
oci8.c: In function `php_if_ocicollassignelem':
oci8.c:4604: `dword' undeclared (first use in this function)
oci8.c:4604: (Each undeclared identifier is reported only once
oci8.c:4604: for each function it appears in.)
oci8.c:4604: parse error before `)'
oci8.c:4626: parse error before `)'
oci8.c:4657: parse error before `)'

cheers,
Michael




-- 
Edit this bug report at http://bugs.php.net/?id=12260&edit=1

Bug #11999 Updated: Execute a storedprocedure using php

[thies]

 ID:   11999
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.0.6
 New Comment:

your sql is bogus - nothing wrong with php here.



Previous Comments:


[2001-07-10 02:28:43] [EMAIL PROTECTED]

$sql1="execute proctest('$UName','$ase','$dsd',$id,$sno,'$num')";

$proc=OCIParse($conn,$sql1);
 OCIExecute($proc);

Warning: OCIStmtExecute: ORA-00900: invalid SQL statement in
/home/http/sigs/soffline.php on line 65






-- 
Edit this bug report at http://bugs.php.net/?id=11999&edit=1

Bug #11799 Updated: OCIFetchInto/OCI_NUM starts the array at 0 not at 1 as stated in the doc

[thies]

 ID:   11799
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: Win2000
 PHP Version:  4.0.4pl1


Previous Comments:


[2001-06-29 08:44:59] [EMAIL PROTECTED]

$cur=OCIParse($conn, $query);
OCIExecute($cur);
OCIFetchInto($cur, $result,OCI_NUM);

--> $result starts at [0] and not at [1] as written in the
documentation




-- 
Edit this bug report at http://bugs.php.net/?id=11799&edit=1

Bug #11539 Updated: Oracle_Apache / PHP Installing

[thies]

 ID:   11539
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: AIX 4.3.3
 PHP Version:  4.0.6RC3
 New Comment:

reopen if problem is still there



Previous Comments:


[2001-06-19 22:41:03] [EMAIL PROTECTED]

I don't think the OCI8 extension is (yet) compatible
with OCI9 libs. The configure at least seems to think
you have 8.0.x version installed.




[2001-06-19 07:28:01] [EMAIL PROTECTED]

I'm traying new version 4.0.6RC3
./configure --with-oci8=/oracle_ais/ais
--with-apxs=/oracle_ais/ais/Apache/Apache/bin/apxs
was OK
but make gets error (file libnlsrtl3 dosn't exist in all server)

Error message:
Making all in .
/bin/sh /php-4.0.6RC3/libtool --silent --mode=link gcc  -I.
-I/php-4.0.6RC3/ -I/php-4.0.6RC3/main -I/php-4.0.6RC3 -I/include
-I/php-4.0.6RC3/Zend -I/php-4.0.6RC3/ext/mysql/libmysql
-I/oracle_ais/817/rdbms/public -I/oracle_ais/817/rdbms/demo
-I/php-4.0.6RC3/ext/xml/expat/xmltok
-I/php-4.0.6RC3/ext/xml/expat/xmlparse -I/php-4.0.6RC3/TSRM  -DAIX=43
-DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8
-DXML_BYTE_ORDER=21 -O2   -o libphp4.la -rpath /php-4.0.6RC3/libs
-avoid-version -L/oracle_ais/817/lib  -R /oracle_ais/817/lib stub.lo 
Zend/libZend.la  sapi/apache/libsapi.la  main/libmain.la 
regex/libregex.la  ext/mysql/libmysql.la ext/oci8/liboci8.la
ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la
ext/standard/libstandard.la ext/xml/libxml.la  TSRM/libtsrm.la -ldl
-lclntsh -lpsa -lcore4 -lnlsrtl3 -lld -lbsd_r -lm -lodm -ldl -lcrypt
-lbind -lm -ldl
collect2: Library libnlsrtl3 not found
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
oracle1:/php-4.0.6RC3 # 

Thanks for help.




[2001-06-18 16:45:51] [EMAIL PROTECTED]

This should be fixed in latest CVS (and maybe also in the 
PHP 4.0.6RC3) so please try them out. Reopen if still no workie.

Latest CVS:

http://snaps.php.net/

4.0.6RC3

http://www.php.net/~andi/php-4.0.6RC3.tar.gz

(if above link doesn't work, try with RC4)

--Jani




[2001-06-18 10:03:58] [EMAIL PROTECTED]

Hello !
I'm trying to install PHP 4.04pl1 as Apache module with  Apache 1.3.12
installed with Oracle iAS 1.0.2.1

PHP compiled fine with such options:
/configure --with-apxs=../Apache/Apache/bin/apxs
but make install gets errors:

Making install in Zend
Target "install-exec-am" is up to date.
Target "install-data-am" is up to date.
Target "install" is up to date.
Making install in main
Target "install-p" is up to date.
Target "install" is up to date.
Making install in ext
Making install in mysql
Making install in libmysql
/bin/sh /php-4.0.4pl1/libtool --silent --mode=compile gcc  -I.
-I/php-4.0.4pl1/ext/mysql/libmysql -I/php-4.0.4pl1/main -I/php-4.0.4pl1
-I/include -I/php-4.0.4pl1/Zend -I/php-4.0.4pl1/ext/mysql/libmysql
-I/php-4.0.4pl1/ext/xml/expat/xmltok
-I/php-4.0.4pl1/ext/xml/expat/xmlparse -I/php-4.0.4pl1/TSRM  -DAIX=43
-DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DEAPI -DUSE_EXPAT
-DXML_BYTE_ORDER=21 -O2  -c libmysql.c
In file included from libmysql.c:9:
global.h:525: conflicting types for `int8'
/usr/include/sys/inttypes.h:622: previous declaration of `int8'
global.h:526: warning: redefinition of `int16'
/usr/include/sys/inttypes.h:623: warning: `int16' previously declared
here
global.h:536: warning: redefinition of `int32'
/usr/include/sys/inttypes.h:624: warning: `int32' previously declared
here
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.

Can you help me please?
Jana




-- 
Edit this bug report at http://bugs.php.net/?id=11539&edit=1