[PHP-DEV] PHP 4.0 Bug #10265 Updated: Apache dumps core during mysql_fetch_array

2001-05-04 Thread benedict 

ID: 10265
User Update by: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: MySQL related
Bug Type: Date/time related
Description: Apache dumps core during mysql_fetch_array

It took me some time to find out, that this actually
is a bug in date(). Try the following script and have
a look at the H:i:s part of the second date:

snip---
  H:i:s",time())."\n";
flush();
}
?>
snap

(the core dumps only occurred together with mysql,)

Previous Comments:
---

[2001-04-10 12:53:37] [EMAIL PROTECTED]
Apache 1.3.19 dumps core during mysql_fetch_array. The exact point
where this happens seems to be dependent on the number off string
concatenations during the while loop. This happens with mysql versions
3.23.22-beta, 3.23.32, 3.23.36.

configure-line:  ./configure --with-apache=/u/www/src/apache 
--with-config-file-path=/u/www/conf --without-gd --enable-track-vars 
--with-system-regex --with-mysql=/u/www/mysql

gdb backtrace:
www@zentrifuge:~/www.pressbot > gdb bin/httpd core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
Core was generated by `/u/www/www.pressbot/bin/httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /u/www/mysql/lib/mysql/libmysqlclient.so.9...done.Reading symbols 
from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Reading symbols from /lib/libnss_dns.so.2...done.
#0  chunk_alloc (ar_ptr=0x4019c2c0, nb=112) at malloc.c:2814
2814malloc.c: No such file or directory.
(gdb) where
#0  chunk_alloc (ar_ptr=0x4019c2c0, nb=112) at malloc.c:2814
#1  0x4011083c in malloc () at malloc.c:2181
#2  0x80e7d84 in _emalloc (size=90) at zend_alloc.c:158
#3  0x80f245e in concat_function (result=0xbfffd848, op1=0x822c3dc, op2#4  0x8115238 
in execute (op_array=0x821d81c) at ./zend_execute.c:1029
#5  0x80f4f7b in zend_execute_scripts (type=8, file_count=3) at zend.c:#6  0x8091dcb 
in php_execute_script (primary_file=0xb198) at main.c#7  0x8101a4b in 
apache_php_module_main (r=0x8204e74, display_source_mo#8  0x808f375 in send_php ()
#9  0x808f3b6 in send_parsed_php ()
#10 0x8123079 in ap_invoke_handler ()
#11 0x81385ef in process_request_internal ()
#12 0x8138662 in ap_process_request ()
#13 0x812f266 in child_main ()
#14 0x812f4ea in make_child ()
#15 0x812f5a6 in startup_children ()
#16 0x812fc2c in standalone_main ()
#17 0x813045c in main ()
#18 0x400d7a8e in __libc_start_main () at ../sysdeps/generic/libc-start(gdb)   

---


Full Bug description available at: http://bugs.php.net/?id=10265


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10265: Apache dumps core during mysql_fetch_array

2001-04-10 Thread benedict 

From: [EMAIL PROTECTED]
Operating system: Linux  2.2.18
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  Apache dumps core during mysql_fetch_array

Apache 1.3.19 dumps core during mysql_fetch_array. The exact point
where this happens seems to be dependent on the number off string
concatenations during the while loop. This happens with mysql versions
3.23.22-beta, 3.23.32, 3.23.36.

configure-line:  ./configure --with-apache=/u/www/src/apache 
--with-config-file-path=/u/www/conf --without-gd --enable-track-vars 
--with-system-regex --with-mysql=/u/www/mysql

gdb backtrace:
www@zentrifuge:~/www.pressbot > gdb bin/httpd core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
Core was generated by `/u/www/www.pressbot/bin/httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /u/www/mysql/lib/mysql/libmysqlclient.so.9...done.Reading symbols 
from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Reading symbols from /lib/libnss_dns.so.2...done.
#0  chunk_alloc (ar_ptr=0x4019c2c0, nb=112) at malloc.c:2814
2814malloc.c: No such file or directory.
(gdb) where
#0  chunk_alloc (ar_ptr=0x4019c2c0, nb=112) at malloc.c:2814
#1  0x4011083c in malloc () at malloc.c:2181
#2  0x80e7d84 in _emalloc (size=90) at zend_alloc.c:158
#3  0x80f245e in concat_function (result=0xbfffd848, op1=0x822c3dc, op2#4  0x8115238 
in execute (op_array=0x821d81c) at ./zend_execute.c:1029
#5  0x80f4f7b in zend_execute_scripts (type=8, file_count=3) at zend.c:#6  0x8091dcb 
in php_execute_script (primary_file=0xb198) at main.c#7  0x8101a4b in 
apache_php_module_main (r=0x8204e74, display_source_mo#8  0x808f375 in send_php ()
#9  0x808f3b6 in send_parsed_php ()
#10 0x8123079 in ap_invoke_handler ()
#11 0x81385ef in process_request_internal ()
#12 0x8138662 in ap_process_request ()
#13 0x812f266 in child_main ()
#14 0x812f4ea in make_child ()
#15 0x812f5a6 in startup_children ()
#16 0x812fc2c in standalone_main ()
#17 0x813045c in main ()
#18 0x400d7a8e in __libc_start_main () at ../sysdeps/generic/libc-start(gdb)   


-- 
Edit Bug report at: http://bugs.php.net/?id=10265&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #3362 Updated: php_auth_user not passed back to apache

2001-02-26 Thread benedict 

ID: 3362
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Apache related
Description: php_auth_user not passed back to apache

No, this seems to be gone in PHP 4.

Previous Comments:
---

[2001-02-24 13:50:59] [EMAIL PROTECTED]
Does this still occur with PHP 4.0.4pl1?

James

---

[2001-02-10 14:04:16] [EMAIL PROTECTED]
refiled as a bug against 4.0.

---

[2000-01-31 11:10:25] [EMAIL PROTECTED]
When I use a "normal" i.e. htaccess-authenification, apache puts
the username-string into to the (combined) logfile.

When I use the php-authentification, there is no username in
the logfile. So it seems, that apache does not know, that the
user is now authenticated.

Should there perhaps be something like
GLOBAL(php3_rqst)->connection->user=estrdup(user);

in functions/post.c?

I am using php as a module for apache 1.3.9.



---


Full Bug description available at: http://bugs.php.net/?id=3362


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]