#21327 [Opn->Bgs]: MySQL 3.22 compile problem

[georg]

 ID:   21327
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

Please update your MySQL 3.22 (which isn't supported anymore).

If you can't find a good reason for, read MySQL AB Announcement about
security and vulnerability in versions < 3.23.54a



Previous Comments:


[2003-01-01 22:57:58] [EMAIL PROTECTED]

Compiling 4.3.0 with mySQL 3.22 installed. Configures fine, compiles
all the way up until:

/bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 
-rdynamic   ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo
ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo
ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo
ext/dba/dba_db3.lo ext/imap/php_imap.lo ext/ldap/ldap.lo
ext/mysql/php_mysql.lo ext/openssl/openssl.lo ext/overload/overload.lo
ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo
ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
ext/pgsql/pgsql.lo ext/posix/posix.lo ext/session/session.lo
ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo
ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo
ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo
ext/sysvsem/sysvsem.lo ext/sysvshm/sysvshm.lo
ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo
ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo
main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo
main/strlcat.lo main/mergesort.lo main/reentrancy.lo
main/php_variables.lo main/php_ticks.lo main/streams.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/memory_streams.lo main/user_streams.lo
Zend/zend_language_parser.lo Zend/zend_language_scanner.lo
Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo
Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo
Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo
Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo
Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo
Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo
Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo
Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo
Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo
main/internal_functions_cli.lo -lcrypto -lssl -lc-client -lmm -lpq
-lmysqlclient -lldap -llber -lcrypt -lpam -ldb -lz -lcrypt -lssl
-lcrypto -lresolv -lm -ldl -lnsl -lcrypt  -o sapi/cli/php
libtool: link: warning: library `/usr/lib/libmm.la' was moved.
libtool: link: warning: library `/usr/lib/libmm.la' was moved.
ext/mysql/php_mysql.o: In function `zif_mysql_client_encoding':
/muds/websrc/php-4.3.0/ext/mysql/php_mysql.c:1077: undefined reference
to `mysql_character_set_name'
ext/mysql/php_mysql.o: In function `zif_mysql_real_escape_string

#20745 [Com]: socket_accept() in blocking mode doesn't handle signal interrupts

[piotr]

 ID:   20745
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Sockets related
 Operating System: Linux
 PHP Version:  4.2.3
 New Comment:

I'd like to revive this bug .. as of 4.3.0 this beheaviour persists ..
I even tried this define(ticks=1); approach quoted in one of the
related bugs .. it didnt help .. during a call to socket_accept() as
far as I can see (I've tested only with SIGTERM and SIGINT) .. those
handlers never get called .. with the new feature (the 3rd param on
pcntl_signal() .. set to false) .. the socket_accept() call gets
interrupted, but the handler is still not called. I would say there is
a need to resolve this .. right now there is no way to cleanly kill a
daemon process running php unless non blocking sockets are used ..
which is basicaly a waste of cpu cycles .. 

Please respond as to the status of this problem asap.


Previous Comments:


[2002-12-15 04:05:02] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-12-01 14:31:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



[2002-12-01 07:59:34] [EMAIL PROTECTED]

The socket_accept() function doesn't appear to handle kernel level
system interrupts. This is a problem because PHP scripts written to use
pcntl_signal() won't be executed while socket_accept() is in blocking
mode. THAT is a problem because the script can't be killed with:

kill -s SIGUSR1 [pid]

and can't reap zombie processes when SIGCHLD is given (not that is much
of a problem on Linux, since you can use SIG_IGN).

A workaround I've made is to set a socket to non-blocking mode:

socket_set_nonblock($hSocket);

And then use a while loop like so:

while (($hClient = @socket_accept($hSocket)) === false) {
   
   // If this is a real error, we need to handle it. Unfortunately,
in this
   // event we just die() essentially.
   
   if (!is_resource($hSocket)) {

   error_log(socket_strerror(socket_last_error($hSocket)));
   exit;

   }
   
   // We need to sleep for one second so that CPU isn't absorbed
with this
   // process. This may seem clunky, but select() doesn't appear to
work
   // correctly with accept() in PHP in blocking mode (that is
EINTR does
   // not appear to work correctly), thus preventing signals from
being
   // received. This, in effect, makes the process unkillable. This
is the
   // workaround, for the moment.
   
   sleep(1);
   
}

While this works, it would be much better if it just returned when a
system interrupt is given like the C-equivalent does. This works
because the system can't receive messages from the kernel because it
isn't blocking.




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

#21331 [NEW]: SIGINT handler not called during socket_accept() (revive of Bug #20745)

[piotr]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.0
PHP Bug Type: Sockets related
Bug description:  SIGINT handler not called during socket_accept() (revive of Bug 
#20745)

this is meant as a revive of Bug #20745 .. but since its not my bug I
couldnt reopen it myself .. dont know if you guys get messages from
abandoned bugs .. so I opened this one)

(this was tested in the CGI executable from 4.2.3 and with the CLI
executable from 4.3.0)
steps to reproduce:
install a signal handler for SIGINT (using pcntl_signal())
create a socket
bind the socket
start listening on the socket
call socket_accept() on the socket

now hit ctrl-c .. and the handler isnt called .. if the signal handler was
installed with the third parameter set to false .. the call gets
interrupted but the call just fails and the handler is still not called.

if you need any additional information please let me know.
-- 
Edit bug report at http://bugs.php.net/?id=21331&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21331&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21331&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21331&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21331&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21331&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21331&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21331&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21331&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21331&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21331&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21331&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21331&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21331&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21331&r=gnused

#21322 [Opn->Bgs]: Out Put Error from United Parcel Service Rate/Service CGI File

[georg]

 ID:   21322
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: Red Hat Linux 7.1
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

You already submitted this error (bugreport #21023 which has status
feedback!)


Previous Comments:


[2003-01-01 15:39:10] [EMAIL PROTECTED]

Version 4.3.0 has the following problem. 

I have develpoed a script that works with the www.ups.com cgi script to
calculate a shipping rate. The script is having trouble outputing the
entire "string" that is out puted by the
http://www.ups.com/using/services/rave/qcost_dss.cgi file. I have been
using this script for two years and have never had this problem.

##This is a pre-configured United Parcel Service script.##
 $contents");
}
else{
echo "$contents";
fclose($open_sock);
}
?>


##Normaly this script out puts the following stings.
HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Sun, 15 Dec 2002 04:21:03 GMT
Content-type: multipart/mixed;boundary=UPSBOUNDARY
Content-length: 267
Connection: close

POST /using/services/rave/qcost_dss.cgi HTTP/1.0
Content-type: application/x-www-form-urlencoded
Content-length: 270

AppVersion=1.2&AcceptUPSLicenseAgreement=YES&ResponseType=application/x-ups-rss&ActionCode=3&ServiceLevelCode=GND&RateChart=Regular+Daily+Pickup&ShipperPostalCode=55428&ConsigneePostalCode=48235&ConsigneeCountry=US&PackageActualWeight=2&ResidentialInd=0&PackagingType=00








--UPSBOUNDARY
Content-type: application/x-ups-rss
Content-length: 78

UPSOnLine%1.2%%Success%3%GND%55428%US%48235%US%004%2%3.92%0.00%3.92%-1

--UPSBOUNDARY--

#Notice that 3.92 is the actual shipping rate.#

PHP Version 4.3.0 only out puts the first line which is:

HTTP/1.1 200 OK


I love PHP but version 4.3.0 is very bugy. Please fix this bug.




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

#21333 [NEW]: Nesting level too deep - recursive dependency?

[webmaster]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 8.0
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  Nesting level too deep - recursive dependency?

This error message appears on every script, even in this one:



This is just as it looks at the end of ANY php page:

"Fatal error: Nesting level too deep - recursive dependency? in Unknown on
line 0"

Environment:

RedHat Linux8.0 Kernel 2.4.18-14 
Apache 2.0.40
PHP 4.3.0

And this is how I compiled PHP:

./configure i386-redhat-linux \
  --with-apxs2=/usr/sbin/apxs \
  --with-config-file-path=/etc \
  --with-gd \
  --with-zlib \
  --enable-ftp \
  --with-mysql \
  --with-informix=/opt/informix \
  --enable-sockets

-- 
Edit bug report at http://bugs.php.net/?id=21333&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21333&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21333&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21333&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21333&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21333&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21333&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21333&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21333&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21333&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21333&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21333&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21333&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21333&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21333&r=gnused

#21333 [Opn->Fbk]: Nesting level too deep - recursive dependency?

[derick]

 ID:   21333
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: RedHat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

Please run a "make test" after compiling PHP with "make" in the source
directory and press "y" if it asks to send the information to the QA
site.

Derick


Previous Comments:


[2003-01-02 04:47:34] [EMAIL PROTECTED]

This error message appears on every script, even in this one:



This is just as it looks at the end of ANY php page:

"Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0"

Environment:

RedHat Linux8.0 Kernel 2.4.18-14 
Apache 2.0.40
PHP 4.3.0

And this is how I compiled PHP:

./configure i386-redhat-linux \
  --with-apxs2=/usr/sbin/apxs \
  --with-config-file-path=/etc \
  --with-gd \
  --with-zlib \
  --enable-ftp \
  --with-mysql \
  --with-informix=/opt/informix \
  --enable-sockets





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

#21291 [Com]: make failure

[gtanzilli]

 ID:   21291
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Servlet related
 Operating System: Linux Redhat 8
 PHP Version:  4.3.0
 New Comment:

I see there is a problem during configure,
$(builddir) and $(srcdir) in sapi/servlet/Makefile.frag

are ignored in the final Makefile 

also seems that when confiring with --with-java and --with-servlet,
java got disabled.

Unfortunatelly I do not know enougth the new build system to propose a
patch


Previous Comments:


[2002-12-30 07:58:56] [EMAIL PROTECTED]

hi,
servlet SAPI do not compile.
I get this error:

/usr/local/src/php4-STABLE-200212301230/sapi/servlet/servlet.c: In
function `Java_net_php_servlet_startup':
/usr/local/src/php4-STABLE-200212301230/sapi/servlet/servlet.c:264:
warning: passing arg 2 of `php_module_startup' from incompatible
pointer type
make: *** No rule to make target `sapi/servlet/java.c', needed by
`sapi/servlet/java.lo'.  Stop.

thanks




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

#19653 [Com]: sql 2000

[pvy]

 ID:   19653
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: MSSQL related
 Operating System: windowx xp professional
 PHP Version:  4.2.3
 New Comment:

I got some error.
in php*.zip included dll for MSSQL7.0.
Don't copy it to C:\winnt\system23; use dll from your MSSQL server.


Previous Comments:


[2002-09-29 12:54:07] [EMAIL PROTECTED]

I' have php 4.2.3 installed in microsoft Windows Xp professional, with
SQL 2000 from the same company, when i programmed the php dll to access
a Ms SQL 2000 (mssql.dll) the php page send me the follow message:


Warning: MS SQL: Unable to connect to server: Batman in
c:\inetpub\wwwroot\php\sql.php on line 7
Base de datos fallo a conectarse.

the server it's already in use, the login and pasword it's in the
system and the database exist...

the system it's properly installed.

thanks.



[2002-09-28 23:03:42] [EMAIL PROTECTED]

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".

Thank you for your interest in PHP.






[2002-09-28 16:56:10] [EMAIL PROTECTED]

microsoft sql 2000 will not work in php 4.2.3, the driver mssql.dll
can't open the database




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

#20022 [Sus]: OCI8 Recursive call!

[thies]

 ID:   20022
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Suspended
 Bug Type: OCI8 related
 Operating System: Win XP Pro SP1
 PHP Version:  4.2.3
 New Comment:

OCI(in_call) is a thread-local variable. so it's only global the the
current thread.




Previous Comments:


[2002-12-23 07:59:47] [EMAIL PROTECTED]

I have same problem with "OCI8 Recursive call".
This error happens when
PHP works as !ISAPI module! (not CGI) under IIS.

I just analyzed source and think I found where bug is.

In case of ISAPI module 
functions of this extension (and OCI8 calls) can be called
_simultaneously_ (not recursive but parallel) from different threads. 
conclusion: following manner of using flag 'in_call' is erroneous:
 ext/oci8.c -
#define CALL_OCI(call) \
{ \
if (OCI(in_call)) { \
php_error(E_WARNING, "OCI8 Recursive call!\n"); \
exit(-1); \
} else { \
OCI(in_call)=1; \
call; \
OCI(in_call)=0; \
} \
}
#define CALL_OCI_RETURN(retcode,call) \
// ... similar code

I propose two alternatives:
1) remove away this checks
2) use some synchonization mechanizm instead

>as i don't use windows myself there's 
>nothing i can do to
If need, I can provide help
-- 
P.S.
sorry about poor english... 
My native lang. is C/C++ ;)



[2002-10-28 08:39:42] [EMAIL PROTECTED]

as i don't use windows myself there's nothing i can do to 
help you. maybe try to find someone on php-db who has this 
setup working. 
 



[2002-10-28 08:17:30] [EMAIL PROTECTED]

Works OK from commandline !



[2002-10-28 07:50:36] [EMAIL PROTECTED]

I use IIS !
How do i do it from the comman-line ?

Jesper



[2002-10-28 07:47:03] [EMAIL PROTECTED]

oracle9 is fully supported. 
 
does the same happen if you use php from the command line? 
 
BTW: what webserver are you using? 
 



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/20022

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

#21365 [Bgs]: test....

[edink]

 ID:   21365
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: win2k
 PHP Version:  4.3.0
 New Comment:

Does it work now? :)


Previous Comments:


[2003-01-02 17:37:29] [EMAIL PROTECTED]

test. pls ignore.




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

#21364 [Opn->Bgs]: test....

[edink]

 ID:   21364
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: win2k
 PHP Version:  4.3.0


Previous Comments:


[2003-01-02 17:37:09] [EMAIL PROTECTED]

test. pls ignore.




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

#21362 [Opn->Bgs]: test....

[edink]

 ID:   21362
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: win2k
 PHP Version:  4.3.0


Previous Comments:


[2003-01-02 17:32:54] [EMAIL PROTECTED]

test. pls ignore.




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

#21363 [Opn->Bgs]: test....

[edink]

 ID:   21363
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: win2k
 PHP Version:  4.3.0


Previous Comments:


[2003-01-02 17:34:34] [EMAIL PROTECTED]

test. pls ignore.




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

#21374 [Opn->Bgs]: FastCGI -b option doesn't work

[iliaa]

 ID:   21374
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2003-01-02 20:34:14] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the "-b" argument that
should "Bind Path for external FASTCGI server mode" doesn't work.

What happens is:
c:\php>php -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start
FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




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

#21373 [Opn->Bgs]: FastCGI -b option doesn't work

[iliaa]

 ID:   21373
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2003-01-02 20:27:20] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the "-b" argument that
should "Bind Path for external FASTCGI server mode" doesn't work.

What happens is:
c:\php>php -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start
FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




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

#21372 [Opn->Bgs]: FastCGI -b option doesn't work

[iliaa]

 ID:   21372
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2003-01-02 20:13:02] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the "-b" argument that
should "Bind Path for external FASTCGI server mode" doesn't work.

What happens is:
c:\php>php -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start
FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




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

#21371 [Opn->Bgs]: FastCGI -b option doesn't work

[iliaa]

 ID:   21371
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2003-01-02 20:12:49] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the "-b" argument that
should "Bind Path for external FASTCGI server mode" doesn't work.

What happens is:
c:\php>php -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start
FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




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

#21368 [Opn->Bgs]: FastCGI -b option error

[edink]

 ID:   21368
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2003-01-02 19:54:54] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the "-b" argument that
should "Bind Path for external FASTCGI server mode" doesn't work.

What happens is:
c:\php>php -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




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

#21370 [Opn->Bgs]: FastCGI -b option doesn't work

[edink]

 ID:   21370
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2003-01-02 20:10:13] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the "-b" argument that
should "Bind Path for external FASTCGI server mode" doesn't work.

What happens is:
c:\php>php -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start
FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




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

#21357 [Opn->Bgs]: test....

[iliaa]

 ID:   21357
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: win2k
 PHP Version:  4.3.0


Previous Comments:


[2003-01-02 17:16:37] [EMAIL PROTECTED]

test. pls ignore.




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

#21375 [NEW]: Changes in configure.in do not allow the creation of a sane configure

[jmcastagnetto]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4CVS-2003-01-02 (dev)
PHP Bug Type: *Compile Issues
Bug description:  Changes in configure.in do not allow the creation of a sane configure

There have been at least 2 changes since I last built from CVS on Solaris 8
(October 13, 2002)

The first one is the addition to grep of Gnu grep only parameters w/o
checking for the existence of said option in the target OS (changed to gnu
grep manually in configure.in)

The second one is that it seems like the file is using macros from a newer
autoconf (only msg I saw in the logs for configure.in is from rev 1.394:
"Don't use autoconf 2.52 macros.")

If a newer autoconf is required, it should be documented, or a warning
should be generated. Instead of a broken configure that later on fails.

% autoconf --version
Autoconf version 2.13

Tried doing a "buildconf" on today's CVS (2003/01/02) and got:

% ./buildconf
using default Zend directory
rebuilding configure
configure.in:831: /opt/sfw/bin/gm4: Undefined macro `AC_PROG_LIBTOOL'
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
configure.in:1064:AC_PROG_LIBTOOL
configure.in:1142:AC_DEFINE([HAVE_BUILD_DEFS_H], 1, [ ])
configure.in:146:AC_MSG_RESULT(${1}.${2} (ok))
configure.in:166:AC_MSG_RESULT(${1}.${2}.${3} (ok))
configure.in:238:AC_MSG_RESULT([$PHP_SAPI])
configure.in:295:  AC_DEFINE(HAVE_LIBDL, 1, [ ])
configure.in:422:  AC_DEFINE(HAVE_SOCKADDR_STORAGE,1,[Whether you have
struct sockaddr_storage])
configure.in:431:[AC_DEFINE(HAVE_SOCKADDR_LEN,1,[Whether sockaddr struct
has sa_len])],
configure.in:518:  AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the
getaddrinfo function])
configure.in:545:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t])
configure.in:547:  AC_DEFINE(in_addr_t, u_int, [ ])
configure.in:635:  AC_DEFINE(PHP_SAFE_MODE,1,[ ])
configure.in:637:  AC_DEFINE(PHP_SAFE_MODE,0,[ ])
configure.in:647: 
AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
configure.in:648:  AC_MSG_RESULT([/usr/local/php/bin])
configure.in:650: 
AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,"$withval", [ ])
configure.in:651:  AC_MSG_RESULT([$withval])
configure.in:654:   
AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
configure.in:655:AC_MSG_RESULT([/usr/local/php/bin])
configure.in:658:  AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin",
[ ])
configure.in:659:  AC_MSG_RESULT([/usr/local/php/bin])
configure.in:666:  AC_DEFINE(PHP_SIGCHILD, 1, [ ])
configure.in:668:  AC_DEFINE(PHP_SIGCHILD, 0, [ ])
configure.in:675:  AC_DEFINE(MAGIC_QUOTES, 1, [ ])
configure.in:677:  AC_DEFINE(MAGIC_QUOTES, 0, [ ])
configure.in:700:  AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,"1",[ ])
configure.in:702:  AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,"0",[ ])
configure.in:712:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have dmalloc])
configure.in:723:  AC_DEFINE(HAVE_IPV6,1,[Whether to enable IPv6
support])
configure.in:742:  AC_DEFINE(HAVE_CRYPT,1,[ ]) 
configure.in:795:AC_MSG_RESULT([$PHP_VERSIONING])
configure.in:840:  AC_DEFINE(ZTS,1,[ ])
configure.in:961:AC_DEFINE_UNQUOTED(PHP_BUILD_DATE,"$PHP_BUILD_DATE",[PHP
build date])
configure.in:963:AC_DEFINE_UNQUOTED(PHP_UNAME,"$PHP_UNAME",[uname -a
output])
configure.in:965:AC_DEFINE_UNQUOTED(PHP_OS,"$PHP_OS",[uname output])
rebuilding main/php_config.h.in
configure.in:831: /opt/sfw/bin/gm4: Undefined macro `AC_PROG_LIBTOOL'

which produced a 'configure' file, which when run as:

% ./configure --prefix=/export/dredox1/devel_server/php \
--with-config-file-path=/export/dredox1/devel_server/php \
--enable-track-vars --enable-magic-quotes \
--enable-inline-optimization \
--enable-xml \
--enable-pcntl \
--enable-cli \
--with-gmp \
--enable-aggregate \
--enable-overload \
--enable-wddx \
--enable-ftp --enable-calendar --enable-bcmath --enable-trans-id\
--with-zlib \
--with-gd \
--enable-freetype-4bit-antialias-hack \
--with-jpeg-dir=/opt/sfw \
--with-png-dir=/opt/sfw \
--with-xpm-dir=/opt/sfw \
--with-ttf=/opt/sfw \
--with-t1lib=/asd/metallo1/server/libs/t1 \
--with-xmlrpc \
--with-mysql=/export/dredox1/devel_server/mysql

Gave the error:
...
checking for isnan... yes
checking whether fp_except is defined... no
checking whether dlsym() requires a leading underscore in symbol names...
./configure: syntax error at line 81725: `_LT_AC_TRY_DLOPEN_SELF'
unexpected
...


-- 
Edit bug report at http://bugs.php.net/?id=21375&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21375&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21375&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21375&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21375&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21375&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21375&r=support

#21346 [Opn->Fbk]: Config fails: checking size of char

[iliaa]

 ID:   21346
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: OpenBSD 3.1-stable
 PHP Version:  4.3.0
 New Comment:

If you do not use the --with-imagick (how did you get it btw?) does it
compile properly?


Previous Comments:


[2003-01-02 13:39:33] [EMAIL PROTECTED]

This error seemed to appear with 4.3.0 final - I compiled a 
new version just a few days ago without seeing this error 
during configure:

checking size of char... configure: error: cannot compute 
sizeof (char), 77

My configure command is:

./configure --with-apxs=/usr/sbin/apxs 
--with-mysql=/usr/local --with-pdflib --enable-exif 
--with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 
--with-zlib --with-openssl --with-gettext --with-ldap 
--with-mhash --disable-overload --enable-sockets 
--with-mcrypt --enable-sysvshm --enable-pcntl 
--with-config-file-path=/var/www/conf/php43/ 
--enable-mbstring --with-pear=/usr/local/lib/php 
--enable-bcmath --with-imagick




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

#21376 [NEW]: References to object members seem to be backwards

[mattb]

From: [EMAIL PROTECTED]
Operating system: GNU/Linux 2.4.18-19.7.x (RedHat)
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  References to object members seem to be backwards

ereg(..., null) is causing a crash in Apache, but not in command line mode.
I'm using the following file in /path/to/htdocs/test.php:



Nothing fancy, just trying to call ereg() with an unset variable as a
second argument (the nusoap package at http://dietrich.ganx4.com/nusoap/
does this all over the place). This used to work just fine with 4.2.3.

If I run it from the 4.3.0 command line, it works as well:

$ php test.php
ereg() test: one
X-Powered-By: PHP/4.1.2
Content-Type: text/plain

one
ereg() test: two
two

However, if I go to that page in a web browser, I get nothing back and
this in the logs:

ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes

The weird thing is that if I call ereg('', ''); once in the program before
all other ereg() calls, everything works as before (shared state
initialization? are these thread safe?).

I'm using apache_1.3.27, curl-7.10.2, libxml2-2.4.30, libxslt-1.0.23,
mod_ssl-2.8.11-1.3.27, openssl-engine-0.9.6g, and php-4.3.0 (everything
else comes from the most up-to-date RedHat 7.3 distro).

Here is my Apache 1.3.27 build configuration (pretty simple). I'm using 

EAPI_MM=SYSTEM SSL_BASE="${ARENA_HOME}" ./configure \
--disable-module=userdir \
--enable-module=ssl \
--enable-shared=ssl \
--enable-shared=max \
"--prefix=${ARENA_HOME}" \
--with-layout=GNU

Here is my PHP 4.3.0 build configuration:

EXTRA_LDFLAGS="-L/usr/X11R6/lib -lpthread" ./configure \
--disable-short-tags \
--disable-rpath \
--disable-url-fopen-wrapper \
--enable-bcmath \
--enable-calendar \
--enable-debugger \
--enable-dio \
--enable-discard-path \
--enable-embed=shared \
--enable-exif \
--enable-force-cgi-redirect \
--enable-ftp \
--enable-inline-optimization \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-mailparse \
--enable-memory-limit \
--enable-mime-magic \
--enable-safe-mode \
--enable-shmop \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx \
"--prefix=${ARENA_HOME}" \
"--with-apxs=${ARENA_HOME}/sbin/apxs" \
--with-bz2=shared \
"--with-config-file-path=${ARENA_HOME}/etc" \
--with-db3 \
"--with-curl=shared,${ARENA_HOME}" \
"--with-dom=${ARENA_HOME}" \
"--with-dom-exslt=${ARENA_HOME}" \
"--with-dom-xslt=${ARENA_HOME}" \
--with-expat-dir=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext=shared \
--with-gmp \
--with-iconv=shared \
--with-imap=shared \
"--with-imap-ssl=${ARENA_HOME}" \
--with-jpeg-dir=/usr \
--with-kerberos \
--with-layout=GNU \
--with-mysql=shared,/usr \
--with-ncurses=shared \
"--with-openssl=shared,${ARENA_HOME}" \
--with-pgsql=shared \
--with-pic \
--with-png-dir=/usr \
--with-pspell=shared \
--with-readline \
--with-regex=system \
--with-ttf=shared \
--with-xmlrpc=shared \
--with-xpm-dir=/usr/X11R6 \
--with-zlib \
--x-includes=/usr/X11R6/include/X11 \
--x-libraries=/usr/X11R6/lib

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

#21377 [NEW]: Tomcat crashes

[brady]

From: [EMAIL PROTECTED]
Operating system: Windows XP Pro
PHP version:  4.3.0
PHP Bug Type: Servlet related
Bug description:  Tomcat crashes

Tomcat is crashing when the servlet tries to execute php. Im using sun jdk
(1.4) and tomcat 4.1.12. This is the dump I get: 



An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0xC0616F5
Function=zend_startup_module+0xD5
Library=c:\php\php4ts.dll

Current Java thread:
at net.php.servlet.startup(Native Method)
at net.php.servlet.init(servlet.java:156)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:924)
- locked <0339FD50> (a org.apache.catalina.core.StandardWrapper)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:658)
- locked <0339FD50> (a org.apache.catalina.core.StandardWrapper)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)

at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)

at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380)

at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
at java.lang.Thread.run(Thread.java:536)

Dynamic libraries:
0x0040 - 0x00406000 C:\j2sdk1.4.1_01\bin\java.exe
0x77F5 - 0x77FF7000 C:\WINDOWS\System32\ntdll.dll
0x77E6 - 0x77F46000 C:\WINDOWS\system32\kernel32.dll
0x77DD - 0x77E5D000 C:\WINDOWS\system32\ADVAPI32.dll
0x7800 - 0x78086000 C:\WINDOWS\system32\RPCRT4.dll
0x77C1 - 0x77C63000 C:\WINDOWS\system32\MSVCRT.dll
0x6D33 - 0x6D45A000 C:\j2sdk1.4.1_01\jre\bin\client\jvm.dll
0x77D4 - 0x77DC6000 C:\WINDOWS\system32\USER32.dll
0x77C7 - 0x77CB C:\WINDOWS\system32\GDI32.dll
0x76B4 - 0x76B6C000 C:\WINDOWS\System32\WINMM.dll
0x6D1D - 0x6D1D7000 C:\j2sdk1.4.1_01\jre\bin\hpi.dll
0x6D30 - 0x6D30D000 C:\j2sdk1.4.1_01\jre\bin\verify.dll
0x6D21 - 0x6D229000 C:\j2sdk1.4.1_01\jre\bin\java.dll
0x6D32 - 0x6D32D000 C:\j2sdk1.4.1_01\jre\bin\zip.dll
0x6D2D - 0x6D2DE000 C:\j2sdk1.4.1_01\jre\bin\net.dll
0x71AD - 0x71AD8000 C:\WINDOWS\System32\WSOCK32.dll
0x71AB - 0x71AC5000 C:\WINDOWS\System32\WS2_32.dll
0x71AA - 0x71AA8000 C:\WINDOWS\System32\WS2HELP.dll
0x71A5 - 0x71A8B000 C:\WINDOWS\System32\mswsock.dll
0x76F2 - 0x76F45000 C:\WINDOWS\System32\DNSAPI.dll
0x76FB - 0x76FB7000 C:\WINDOWS\System32\winrnr.dll
0x76F6 - 0x76F8C000 C:\WINDOWS\system32\WLDAP32.dll
0

#21378 [NEW]: COM code crashes after update 4.2.1 to 4.3.0

[joona]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 pro sp2
PHP version:  4.3.0
PHP Bug Type: COM related
Bug description:  COM code crashes after update 4.2.1 to 4.3.0

COM code that works perfectly ok with 4.2.1 gets Apache 1.3.22 down with
program error notice in PHP 4.3.0. Any documentation update possibly,
maybe?


-- 
Edit bug report at http://bugs.php.net/?id=21378&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21378&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21378&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21378&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21378&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21378&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21378&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21378&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21378&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21378&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21378&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21378&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21378&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21378&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21378&r=gnused

#21376 [Opn]: ereg(..., $unsetVar) crashes Apache in emalloc() / ecalloc()

[mattb]

 ID:   21376
 User updated by:  [EMAIL PROTECTED]
-Summary:  References to object members seem to be backwards
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.4.18-19.7.x (RedHat)
 PHP Version:  4.3.0
 New Comment:

changing title...


Previous Comments:


[2003-01-02 21:23:42] [EMAIL PROTECTED]

ereg(..., null) is causing a crash in Apache, but not in command line
mode. I'm using the following file in /path/to/htdocs/test.php:



Nothing fancy, just trying to call ereg() with an unset variable as a
second argument (the nusoap package at
http://dietrich.ganx4.com/nusoap/ does this all over the place). This
used to work just fine with 4.2.3.

If I run it from the 4.3.0 command line, it works as well:

$ php test.php
ereg() test: one
X-Powered-By: PHP/4.1.2
Content-Type: text/plain

one
ereg() test: two
two

However, if I go to that page in a web browser, I get nothing back and
this in the logs:

ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes

The weird thing is that if I call ereg('', ''); once in the program
before all other ereg() calls, everything works as before (shared state
initialization? are these thread safe?).

I'm using apache_1.3.27, curl-7.10.2, libxml2-2.4.30, libxslt-1.0.23,
mod_ssl-2.8.11-1.3.27, openssl-engine-0.9.6g, and php-4.3.0 (everything
else comes from the most up-to-date RedHat 7.3 distro).

Here is my Apache 1.3.27 build configuration (pretty simple). I'm using


EAPI_MM=SYSTEM SSL_BASE="${ARENA_HOME}" ./configure \
--disable-module=userdir \
--enable-module=ssl \
--enable-shared=ssl \
--enable-shared=max \
"--prefix=${ARENA_HOME}" \
--with-layout=GNU

Here is my PHP 4.3.0 build configuration:

EXTRA_LDFLAGS="-L/usr/X11R6/lib -lpthread" ./configure \
--disable-short-tags \
--disable-rpath \
--disable-url-fopen-wrapper \
--enable-bcmath \
--enable-calendar \
--enable-debugger \
--enable-dio \
--enable-discard-path \
--enable-embed=shared \
--enable-exif \
--enable-force-cgi-redirect \
--enable-ftp \
--enable-inline-optimization \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-mailparse \
--enable-memory-limit \
--enable-mime-magic \
--enable-safe-mode \
--enable-shmop \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx \
"--prefix=${ARENA_HOME}" \
"--with-apxs=${ARENA_HOME}/sbin/apxs" \
--with-bz2=shared \
"--with-config-file-path=${ARENA_HOME}/etc" \
--with-db3 \
"--with-curl=shared,${ARENA_HOME}" \
"--with-dom=${ARENA_HOME}" \
"--with-dom-exslt=${ARENA_HOME}" \
"--with-dom-xslt=${ARENA_HOME}" \
--with-expat-dir=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext=shared \
--with-gmp \
--with-iconv=shared \
--with-imap=shared \
"--with-imap-ssl=${ARENA_HOME}" \
--with-jpeg-dir=/usr \
--with-kerberos \
--with-layout=GNU \
--with-mysql=shared,/usr \
--with-ncurses=shared \
"--with-openssl=shared,${ARENA_HOME}" \
--with-pgsql=shared \
--with-pic \
--with-png-dir=/usr \
--with-pspell=shared \
--with-readline \
--with-regex=system \
--with-ttf=shared \
--with-xmlrpc=shared \
--with-xpm-dir=/usr/X11R6 \
--with-zlib \
--x-includes=/usr/X11R6/include/X11 \
--x-libraries=/usr/X11R6/lib





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

#21378 [Opn]: COM code crashes after update 4.2.1 to 4.3.0

[joona]

 ID:   21378
 User updated by:  [EMAIL PROTECTED]
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: COM related
 Operating System: Windows 2000 pro sp2
 PHP Version:  4.3.0
 New Comment:

-


Previous Comments:


[2003-01-02 21:26:17] [EMAIL PROTECTED]

COM code that works perfectly ok with 4.2.1 gets Apache 1.3.22 down
with program error notice in PHP 4.3.0. Any documentation update
possibly, maybe?






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

#21379 [NEW]: Add integer to pop and unshift

[c . greenNOSP]

From: [EMAIL PROTECTED]
Operating system: RH 7.3
PHP version:  4.3.0
PHP Bug Type: Feature/Change Request
Bug description:  Add integer to pop and unshift

It would be nice if pop and unshift had an optional integer argument.  This
would be useful for retreiving or removing the first or last n elements of
an array.  

If the default is left as 1, then no current code will be affected, and
the functions would be extended in an intuitive way.

Cheerio,

Cameron Green
-- 
Edit bug report at http://bugs.php.net/?id=21379&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21379&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21379&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21379&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21379&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21379&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21379&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21379&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21379&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21379&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21379&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21379&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21379&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21379&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21379&r=gnused

#21380 [NEW]: Ability to assign to $this in constructor of class

[matt-php]

From: [EMAIL PROTECTED]
Operating system: Linux (redhat)
PHP version:  4.3.0
PHP Bug Type: Class/Object related
Bug description:  Ability to assign to $this in constructor of class

(Stig asked me to report this.) Here's the code and the explanation will
follow:
--
class Error {
  var $e = '';
  
  function Error($msg) {
  $this->e = $msg;
  }
}

class Foo {
  var $n;
  function &Foo($n) {
if ($n < 0) {
  // note use of assignment operator "="
  $this = new Error('Foo does not like that
negative stuff');
} else {
$this->n = $n;
}
  }
}

$a = new Foo(-1);
print_r($a);

Outputs:
error Object
(
[e] => Foo does not like that negative stuff
)
--
Currently, if one assignes to $this in the constructor using the
assignment operator (=) the $this reference will be overwritten and so the
constructor will return something other than the object requested by the
new operator.

This does not appear to apply to the assign by reference operator (=&)
that is, it doesn't appear to be possible to overwrite the reference in
$this with another reference. However, using "=" allows one to set $this
to anything; it doesn't even have to be an object and that item will be
returned from the new operator via the constructor.

The question is, is this a feature, and if so, will it continue to be so?
Or, is it a bug? If it's a feature it makes returning a PEAR error object
quite simple and furthermore I have seen some PEAR code (can't remember
where exactly) that uses this feature so if it is a bug that will have to
be fixed too. I would like to know if this can be relied upon into the
future.

'./configure' '--prefix=/usr/local' '--with-pspell' '--with-imap'
'--with-imap-ssl' '--with-gettext'
'--with-apache=/usr/local/src/apache_1.3.27' '--with-mysql=/usr'
'--enable-force-cgi-redirect' '--enable-bcmath' '--enable-discard-path'
'--enable-pear' '--with-kerberos' '--with-zlib' '--enable-ftp' '--with-mm'
'--enable-force-cgi-redirect' 

Thanks,
Matt Friedman.
-- 
Edit bug report at http://bugs.php.net/?id=21380&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21380&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21380&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21380&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21380&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21380&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21380&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21380&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21380&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21380&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21380&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21380&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21380&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21380&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21380&r=gnused

#20426 [NoF->Opn]: php.exe refused to end process: can not close connection to MSSQL

[ulysses]

 ID:   20426
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Windows 2000 Server
-PHP Version:  4.2.3
+PHP Version:  4.30
 New Comment:

OK... I've Just installed latest PHP 4.30, and the crashing 
problem is getting WORSE!

Now PHP will crash whenever I just execute "select *" from 
any table that contains two or more datetime/smalldatetime  
columns.

Again, this crashing situation disappears when I switch 
default script of Windows2000 to Japaness. But I can not 
tell my customers to do this. 

Could you nice guys just DISABLE the auto date format 
converting feature ? To us, this is not a feature; it's a 
CURSE!


Previous Comments:


[2002-11-26 20:03:47] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-11-15 01:36:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

you don't need to open new reports, you can reclassify them..(and this
belongs in mssql)




[2002-11-15 01:36:03] [EMAIL PROTECTED]

OK, I fonud the source of this problem. It's not MSSQL 
lock/transaction problem, nor Windows 2000 Server/
Profession issue. It's due to i18n locallization settings. 
You may not be able to reproduce this cause I'm using 
TRADITINOAL CHINESE version of Windows 2000 Server and 
TRADITINOAL CHINESE version of SQL Server 2000.

Thanks for not responding. You may close this topic, cause 
this is a re-producable crash. I'm going to raise another 
topic.



[2002-11-15 01:15:23] [EMAIL PROTECTED]

OK, I fonud the source of this problem. It's not MSSQL 
lock/transaction problem, nor Windows 2000 Server/
Profession issue. It's due to i18n locallization settings. 
You may not be able to reproduce this cause I'm using 
TRADITINOAL CHINESE version of Windows 2000 Server and 
TRADITINOAL CHINESE version of SQL Server 2000.

Thanks for not responding. You may close this topic, cause 
this is a re-producable crash. I'm going to raise another 
topic.



[2002-11-14 21:29:32] [EMAIL PROTECTED]

The problem came back again. Service Pack did not fixed the 
problem. I'll try to reduce all unrelated code, and find 
out where the problem is.



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/20426

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

#21380 [Opn]: Ability to assign to $this in constructor of class

[matt-php]

 ID:   21380
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Class/Object related
 Operating System: Linux (redhat)
 PHP Version:  4.3.0
 New Comment:

Certainly not a big deal but it was Jesus M. Castagnetto that asked me
to report this, not Stig. Thanks.


Previous Comments:


[2003-01-02 22:20:38] [EMAIL PROTECTED]

(Stig asked me to report this.) Here's the code and the explanation
will follow:
--
class Error {
  var $e = '';
  
  function Error($msg) {
  $this->e = $msg;
  }
}

class Foo {
  var $n;
  function &Foo($n) {
if ($n < 0) {
  // note use of assignment operator "="
  $this = new Error('Foo does not like that
negative stuff');
} else {
$this->n = $n;
}
  }
}

$a = new Foo(-1);
print_r($a);

Outputs:
error Object
(
[e] => Foo does not like that negative stuff
)
--
Currently, if one assignes to $this in the constructor using the
assignment operator (=) the $this reference will be overwritten and so
the constructor will return something other than the object requested
by the new operator.

This does not appear to apply to the assign by reference operator (=&)
that is, it doesn't appear to be possible to overwrite the reference in
$this with another reference. However, using "=" allows one to set
$this to anything; it doesn't even have to be an object and that item
will be returned from the new operator via the constructor.

The question is, is this a feature, and if so, will it continue to be
so? Or, is it a bug? If it's a feature it makes returning a PEAR error
object quite simple and furthermore I have seen some PEAR code (can't
remember where exactly) that uses this feature so if it is a bug that
will have to be fixed too. I would like to know if this can be relied
upon into the future.

'./configure' '--prefix=/usr/local' '--with-pspell' '--with-imap'
'--with-imap-ssl' '--with-gettext'
'--with-apache=/usr/local/src/apache_1.3.27' '--with-mysql=/usr'
'--enable-force-cgi-redirect' '--enable-bcmath' '--enable-discard-path'
'--enable-pear' '--with-kerberos' '--with-zlib' '--enable-ftp'
'--with-mm' '--enable-force-cgi-redirect' 

Thanks,
Matt Friedman.




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

#20426 [Com]: php.exe refused to end process: can not close connection to MSSQL

[ulysses]

 ID:   20426
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Windows 2000 Server
 PHP Version:  4.30
 New Comment:

For more detailed information:

1. On Trad. Chinese version Windows 2000 with Trad. Chinese 
MSSQL 2000, I will get date format like '2003-01-06 
10:23:00' when I execute "select *" in Quary Analyzer. But 
I will get response like '2003 ¤@¤ë 06 10:23 ¤W¤È' when 
executing the same query with PHP.

2. I've tried to change date/number format settings in 
Windowd Location control panel, not working.

3. I've tried to change database default encoding, not 
working.

4. I've tried to add mssql.datetimeconvert=0 AND 
mssql.datetimeconvert=Off in php.ini, not working.

5. The ONLY way to alter the date-format converting style 
of php_mssql is to change the default language script of 
Windows 2000.

For detailed description of the crashing problem:

1. When executing "select *" from any table that contains 
ONE datetime/smalldatetime format column, PHP will execute 
and output text to browser. But that php.exe process will 
not end, neither calling mssql_close() nor not. You can see 
it in the Task Manager, and it can not be stopper by 
clicking "End Process".

2. When executing "select *" from any table that contains 
TWO OR MORE datetime/smalldatetime format column, PHP will 
crashed upon calling mssql_query. Again, that php.exe 
process will not quit and can not be forced quit using Task 
Manager.

3. By switching Windows 2000 default script to Japaness, 
all this problem disappears.

4. I've tried ALL other data format. None would cause 
crashing like this.

Now I'm 100% sure this IS a date-format converting bug. And 
now I'm just asking for one thing: to disable this 
"feature". Please! I beg you!


Previous Comments:


[2003-01-02 22:23:39] [EMAIL PROTECTED]

OK... I've Just installed latest PHP 4.30, and the crashing 
problem is getting WORSE!

Now PHP will crash whenever I just execute "select *" from 
any table that contains two or more datetime/smalldatetime  
columns.

Again, this crashing situation disappears when I switch 
default script of Windows2000 to Japaness. But I can not 
tell my customers to do this. 

Could you nice guys just DISABLE the auto date format 
converting feature ? To us, this is not a feature; it's a 
CURSE!



[2002-11-26 20:03:47] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-11-15 01:36:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

you don't need to open new reports, you can reclassify them..(and this
belongs in mssql)




[2002-11-15 01:36:03] [EMAIL PROTECTED]

OK, I fonud the source of this problem. It's not MSSQL 
lock/transaction problem, nor Windows 2000 Server/
Profession issue. It's due to i18n locallization settings. 
You may not be able to reproduce this cause I'm using 
TRADITINOAL CHINESE version of Windows 2000 Server and 
TRADITINOAL CHINESE version of SQL Server 2000.

Thanks for not responding. You may close this topic, cause 
this is a re-producable crash. I'm going to raise another 
topic.



[2002-11-15 01:15:23] [EMAIL PROTECTED]

OK, I fonud the source of this problem. It's not MSSQL 
lock/transaction problem, nor Windows 2000 Server/
Profession issue. It's due to i18n locallization settings. 
You may not be able to reproduce this cause I'm using 
TRADITINOAL CHINESE version of Windows 2000 Server and 
TRADITINOAL CHINESE version of SQL Server 2000.

Thanks for not responding. You may close this topic, cause 
this is a re-producable crash. I'm going to raise another 
topic.



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/20426

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

#20426 [Com]: php.exe refused to end process: can not close connection to MSSQL

[ulysses]

 ID:   20426
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Windows 2000 Server
 PHP Version:  4.30
 New Comment:

OK... here goes more detail...

Just tried PHP 4.30 ISAPI mode. It still crashed, but now it would
response messages like this:

"PHP has encountered an Access Violation at 77FCB032"

And more crashing condition:

In both CGI and ISAPI mode, PHP will crash when executing "select *"
from any table that contains ONE, TWO OR MORE datetime/smalldatetime
format columns THAT THERE IS ANY OTHER COLUMN BEHIND these datetime
columns.

for example:

example_table (
  sn int,
  title varchar(40),
  modifytime datetime
);

Executing "SELECT sn, title, modifytime FROM example_table" will be
okay, but executing "SELECT sn, modifytime, title FROM example_table"
will crash.


Previous Comments:


[2003-01-02 23:11:12] [EMAIL PROTECTED]

For more detailed information:

1. On Trad. Chinese version Windows 2000 with Trad. Chinese 
MSSQL 2000, I will get date format like '2003-01-06 
10:23:00' when I execute "select *" in Quary Analyzer. But 
I will get response like '2003 ¤@¤ë 06 10:23 ¤W¤È' when 
executing the same query with PHP.

2. I've tried to change date/number format settings in 
Windowd Location control panel, not working.

3. I've tried to change database default encoding, not 
working.

4. I've tried to add mssql.datetimeconvert=0 AND 
mssql.datetimeconvert=Off in php.ini, not working.

5. The ONLY way to alter the date-format converting style 
of php_mssql is to change the default language script of 
Windows 2000.

For detailed description of the crashing problem:

1. When executing "select *" from any table that contains 
ONE datetime/smalldatetime format column, PHP will execute 
and output text to browser. But that php.exe process will 
not end, neither calling mssql_close() nor not. You can see 
it in the Task Manager, and it can not be stopper by 
clicking "End Process".

2. When executing "select *" from any table that contains 
TWO OR MORE datetime/smalldatetime format column, PHP will 
crashed upon calling mssql_query. Again, that php.exe 
process will not quit and can not be forced quit using Task 
Manager.

3. By switching Windows 2000 default script to Japaness, 
all this problem disappears.

4. I've tried ALL other data format. None would cause 
crashing like this.

Now I'm 100% sure this IS a date-format converting bug. And 
now I'm just asking for one thing: to disable this 
"feature". Please! I beg you!



[2003-01-02 22:23:39] [EMAIL PROTECTED]

OK... I've Just installed latest PHP 4.30, and the crashing 
problem is getting WORSE!

Now PHP will crash whenever I just execute "select *" from 
any table that contains two or more datetime/smalldatetime  
columns.

Again, this crashing situation disappears when I switch 
default script of Windows2000 to Japaness. But I can not 
tell my customers to do this. 

Could you nice guys just DISABLE the auto date format 
converting feature ? To us, this is not a feature; it's a 
CURSE!



[2002-11-26 20:03:47] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-11-15 01:36:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

you don't need to open new reports, you can reclassify them..(and this
belongs in mssql)




[2002-11-15 01:36:03] [EMAIL PROTECTED]

OK, I fonud the source of this problem. It's not MSSQL 
lock/transaction problem, nor Windows 2000 Server/
Profession issue. It's due to i18n locallization settings. 
You may not be able to reproduce this cause I'm using 
TRADITINOAL CHINESE version of Windows 2000 Server and 
TRADITINOAL CHINESE version of SQL Server 2000.

Thanks for not responding. You may close this topic, cause 
this is a re-producable crash. I'm going to raise another 
topic.



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/20426

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

#21369 [Opn->Dup]: References to object members seem to be backwards

[mattb]

 ID:   21369
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Duplicate
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.4.18-19.7.x (RedHat)
 PHP Version:  4.3.0
 New Comment:

This is a duplicate of #21376.


Previous Comments:


[2003-01-02 20:07:23] [EMAIL PROTECTED]

ereg(..., null) is causing a crash in Apache, but not in command line
mode. I'm using the following file in /path/to/htdocs/test.php:



Nothing fancy, just trying to call ereg() with an unset variable as a
second argument (the nusoap package at
http://dietrich.ganx4.com/nusoap/ does this all over the place). This
used to work just fine with 4.2.3.

If I run it from the 4.3.0 command line, it works as well:

$ php test.php
ereg() test: one
X-Powered-By: PHP/4.1.2
Content-Type: text/plain

one
ereg() test: two
two

However, if I go to that page in a web browser, I get nothing back and
this in the logs:

ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes

The weird thing is that if I call ereg('', ''); once in the program
before all other ereg() calls, everything works as before (shared state
initialization? are these thread safe?).

I'm using apache_1.3.27, curl-7.10.2, libxml2-2.4.30, libxslt-1.0.23,
mod_ssl-2.8.11-1.3.27, openssl-engine-0.9.6g, and php-4.3.0 (everything
else comes from the most up-to-date RedHat 7.3 distro).

Here is my Apache 1.3.27 build configuration (pretty simple). I'm using


EAPI_MM=SYSTEM SSL_BASE="${ARENA_HOME}" ./configure \
--disable-module=userdir \
--enable-module=ssl \
--enable-shared=ssl \
--enable-shared=max \
"--prefix=${ARENA_HOME}" \
--with-layout=GNU

Here is my PHP 4.3.0 build configuration:

EXTRA_LDFLAGS="-L/usr/X11R6/lib -lpthread" ./configure \
--disable-short-tags \
--disable-rpath \
--disable-url-fopen-wrapper \
--enable-bcmath \
--enable-calendar \
--enable-debugger \
--enable-dio \
--enable-discard-path \
--enable-embed=shared \
--enable-exif \
--enable-force-cgi-redirect \
--enable-ftp \
--enable-inline-optimization \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-mailparse \
--enable-memory-limit \
--enable-mime-magic \
--enable-safe-mode \
--enable-shmop \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx \
"--prefix=${ARENA_HOME}" \
"--with-apxs=${ARENA_HOME}/sbin/apxs" \
--with-bz2=shared \
"--with-config-file-path=${ARENA_HOME}/etc" \
--with-db3 \
"--with-curl=shared,${ARENA_HOME}" \
"--with-dom=${ARENA_HOME}" \
"--with-dom-exslt=${ARENA_HOME}" \
"--with-dom-xslt=${ARENA_HOME}" \
--with-expat-dir=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext=shared \
--with-gmp \
--with-iconv=shared \
--with-imap=shared \
"--with-imap-ssl=${ARENA_HOME}" \
--with-jpeg-dir=/usr \
--with-kerberos \
--with-layout=GNU \
--with-mysql=shared,/usr \
--with-ncurses=shared \
"--with-openssl=shared,${ARENA_HOME}" \
--with-pgsql=shared \
--with-pic \
--with-png-dir=/usr \
--with-pspell=shared \
--with-readline \
--with-regex=system \
--with-ttf=shared \
--with-xmlrpc=shared \
--with-xpm-dir=/usr/X11R6 \
--with-zlib \
--x-includes=/usr/X11R6/include/X11 \
--x-libraries=/usr/X11R6/lib





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

#21376 [Opn]: ereg(..., $unsetVar) crashes Apache in emalloc() / ecalloc()

[mattb]

 ID:   21376
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.4.18-19.7.x (RedHat)
 PHP Version:  4.3.0
 New Comment:

This does not happen if one uses --with-regex=php in the PHP
configuration stage. Apparently, one cannot use --with-regex=system
with Apache (is there a symbol name conflict here?).


Previous Comments:


[2003-01-02 21:26:59] [EMAIL PROTECTED]

changing title...



[2003-01-02 21:23:42] [EMAIL PROTECTED]

ereg(..., null) is causing a crash in Apache, but not in command line
mode. I'm using the following file in /path/to/htdocs/test.php:



Nothing fancy, just trying to call ereg() with an unset variable as a
second argument (the nusoap package at
http://dietrich.ganx4.com/nusoap/ does this all over the place). This
used to work just fine with 4.2.3.

If I run it from the 4.3.0 command line, it works as well:

$ php test.php
ereg() test: one
X-Powered-By: PHP/4.1.2
Content-Type: text/plain

one
ereg() test: two
two

However, if I go to that page in a web browser, I get nothing back and
this in the logs:

ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes

The weird thing is that if I call ereg('', ''); once in the program
before all other ereg() calls, everything works as before (shared state
initialization? are these thread safe?).

I'm using apache_1.3.27, curl-7.10.2, libxml2-2.4.30, libxslt-1.0.23,
mod_ssl-2.8.11-1.3.27, openssl-engine-0.9.6g, and php-4.3.0 (everything
else comes from the most up-to-date RedHat 7.3 distro).

Here is my Apache 1.3.27 build configuration (pretty simple). I'm using


EAPI_MM=SYSTEM SSL_BASE="${ARENA_HOME}" ./configure \
--disable-module=userdir \
--enable-module=ssl \
--enable-shared=ssl \
--enable-shared=max \
"--prefix=${ARENA_HOME}" \
--with-layout=GNU

Here is my PHP 4.3.0 build configuration:

EXTRA_LDFLAGS="-L/usr/X11R6/lib -lpthread" ./configure \
--disable-short-tags \
--disable-rpath \
--disable-url-fopen-wrapper \
--enable-bcmath \
--enable-calendar \
--enable-debugger \
--enable-dio \
--enable-discard-path \
--enable-embed=shared \
--enable-exif \
--enable-force-cgi-redirect \
--enable-ftp \
--enable-inline-optimization \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-mailparse \
--enable-memory-limit \
--enable-mime-magic \
--enable-safe-mode \
--enable-shmop \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx \
"--prefix=${ARENA_HOME}" \
"--with-apxs=${ARENA_HOME}/sbin/apxs" \
--with-bz2=shared \
"--with-config-file-path=${ARENA_HOME}/etc" \
--with-db3 \
"--with-curl=shared,${ARENA_HOME}" \
"--with-dom=${ARENA_HOME}" \
"--with-dom-exslt=${ARENA_HOME}" \
"--with-dom-xslt=${ARENA_HOME}" \
--with-expat-dir=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext=shared \
--with-gmp \
--with-iconv=shared \
--with-imap=shared \
"--with-imap-ssl=${ARENA_HOME}" \
--with-jpeg-dir=/usr \
--with-kerberos \
--with-layout=GNU \
--with-mysql=shared,/usr \
--with-ncurses=shared \
"--with-openssl=shared,${ARENA_HOME}" \
--with-pgsql=shared \
--with-pic \
--with-png-dir=/usr \
--with-pspell=shared \
--with-readline \
--with-regex=system \
--with-ttf=shared \
--with-xmlrpc=shared \
--with-xpm-dir=/usr/X11R6 \
--with-zlib \
--x-includes=/usr/X11R6/include/X11 \
--x-libraries=/usr/X11R6/lib





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

#21376 [Opn->Bgs]: ereg(..., $unsetVar) crashes Apache in emalloc() / ecalloc()

[derick]

 ID:   21376
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.4.18-19.7.x (RedHat)
 PHP Version:  4.3.0
 New Comment:

>From ./configure --help output:

  --with-regex=TYPE   regex library type: system, apache, php.
Default: php
  WARNING: Do NOT use unless you know what you
are doing!

It indeed causes problem if you chose the wrong one, just follow the
advise in the ./configure --help output, it's there for a reason.

Not a bug -> bogus.



Previous Comments:


[2003-01-03 00:33:50] [EMAIL PROTECTED]

This does not happen if one uses --with-regex=php in the PHP
configuration stage. Apparently, one cannot use --with-regex=system
with Apache (is there a symbol name conflict here?).



[2003-01-02 21:26:59] [EMAIL PROTECTED]

changing title...



[2003-01-02 21:23:42] [EMAIL PROTECTED]

ereg(..., null) is causing a crash in Apache, but not in command line
mode. I'm using the following file in /path/to/htdocs/test.php:



Nothing fancy, just trying to call ereg() with an unset variable as a
second argument (the nusoap package at
http://dietrich.ganx4.com/nusoap/ does this all over the place). This
used to work just fine with 4.2.3.

If I run it from the 4.3.0 command line, it works as well:

$ php test.php
ereg() test: one
X-Powered-By: PHP/4.1.2
Content-Type: text/plain

one
ereg() test: two
two

However, if I go to that page in a web browser, I get nothing back and
this in the logs:

ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes
ereg() test: one
FATAL:  emalloc():  Unable to allocate 1449143544 bytes

The weird thing is that if I call ereg('', ''); once in the program
before all other ereg() calls, everything works as before (shared state
initialization? are these thread safe?).

I'm using apache_1.3.27, curl-7.10.2, libxml2-2.4.30, libxslt-1.0.23,
mod_ssl-2.8.11-1.3.27, openssl-engine-0.9.6g, and php-4.3.0 (everything
else comes from the most up-to-date RedHat 7.3 distro).

Here is my Apache 1.3.27 build configuration (pretty simple). I'm using


EAPI_MM=SYSTEM SSL_BASE="${ARENA_HOME}" ./configure \
--disable-module=userdir \
--enable-module=ssl \
--enable-shared=ssl \
--enable-shared=max \
"--prefix=${ARENA_HOME}" \
--with-layout=GNU

Here is my PHP 4.3.0 build configuration:

EXTRA_LDFLAGS="-L/usr/X11R6/lib -lpthread" ./configure \
--disable-short-tags \
--disable-rpath \
--disable-url-fopen-wrapper \
--enable-bcmath \
--enable-calendar \
--enable-debugger \
--enable-dio \
--enable-discard-path \
--enable-embed=shared \
--enable-exif \
--enable-force-cgi-redirect \
--enable-ftp \
--enable-inline-optimization \
--enable-gd-native-ttf \
--enable-magic-quotes \
--enable-mailparse \
--enable-memory-limit \
--enable-mime-magic \
--enable-safe-mode \
--enable-shmop \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx \
"--prefix=${ARENA_HOME}" \
"--with-apxs=${ARENA_HOME}/sbin/apxs" \
--with-bz2=shared \
"--with-config-file-path=${ARENA_HOME}/etc" \
--with-db3 \
"--with-curl=shared,${ARENA_HOME}" \
"--with-dom=${ARENA_HOME}" \
"--with-dom-exslt=${ARENA_HOME}" \
"--with-dom-xslt=${ARENA_HOME}" \
--with-expat-dir=/usr \
--with-freetype-dir=/usr \
--with-gd=shared \
--with-gettext=shared \
--with-gmp \
--with-iconv=shared \
--with-imap=shared \
"--with-imap-ssl=${ARENA_HOME}" \
--with-jpeg-dir=/usr \
--with-kerberos \
--with-layout=GNU \
--with-mysql=shared,/usr \
--with-ncurses=shared \
"--with-openssl=shared,${ARENA_HOME}" \
--with-pgsql=shared \
--with-pic \
--with-png-dir=/usr \
--with-pspell

#21381 [NEW]: apache/gd/freetype/mod_perl

[ruempler]

From: [EMAIL PROTECTED]
Operating system: RedHat 7.2 Kernel 2.4.19
PHP version:  4.3.0
PHP Bug Type: Apache related
Bug description:  apache/gd/freetype/mod_perl

hi,

if i compile php-4.3.0 with the builtin gd, pdflib 4.0.3, postgres
support, freetype 2.0.3 as apache module, there is a problem with apache's
mod_perl:
now the perl GD library does not work any more, we get the error

"libgd was not built with FreeType font support"

although we compiled php with freetype support.

if we install php WITHOUT gd, the mod_perl gd functions are working again
fine.

bug or what? :-)
-- 
Edit bug report at http://bugs.php.net/?id=21381&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21381&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21381&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21381&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21381&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21381&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21381&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21381&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21381&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21381&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21381&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21381&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21381&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21381&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21381&r=gnused

#21337 [Fbk->Opn]: php crashes on ldap_sort

[r . hozee]

 ID:   21337
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: Windows XP
 PHP Version:  4.3.0
 New Comment:

script used:

$ds = ldap_connect("mailservername") 

if ($ds) 
 
   { 
   $ldapbind = ldap_bind($ds, $ldaprdn, $ldappass);
   $sr=ldap_search($ds,"o=my org, c=NL", "cn=*");
   ldap_sort($ds,$sr,"cn");
   $info = ldap_get_entries($ds,$sr);
   //what follows is retrieval of entries
   } 

script works ok if i leave ldap_sort out

it also crashes when i replace
ldap_sort($ds,$sr,"cn");
with
$sr = ldap_sort($ds,$sr,"cn");
or replacing cn with givenname.

I used the precompiled version of php 4.3 from php.net


Previous Comments:


[2003-01-02 14:06:44] [EMAIL PROTECTED]

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".

Thank you for your interest in PHP.


Could you please provide the smallest possible test script that could
be replicate the problem.



[2003-01-02 08:31:55] [EMAIL PROTECTED]

Im using apache 2.0.43 as my webserver.
My ldap server is MS Exchange 5.5.

on ldap_sort my PHP Script Interpreter crashes and gives out this
signature:
szAppName : php.exe szAppVer : 4.3.0.0 szModName : php4ts.dll  
  
szModVer : 4.3.0.0 offset : 000ad517



   




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