#25332 [Opn->Bgs]: Update from 4.3.2 to 4.3.3 won't work
ID: 25332 Updated by: [EMAIL PROTECTED] Reported By: info at y2ksw dot it -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP Pro/ Win 2000 server PHP Version: 4.3.3 New Comment: And you should have searched the bug database before submitting any bug report, after you had asked this on some public mailing list. There are always dozens of reports like this after we release new version. Previous Comments: [2003-08-31 14:03:29] info at y2ksw dot it Description: We tried today to make an update and our PHP applications don't work any more. Uninstalling and downgrading to 4.3.2 works perfectly well. We tried first on our win 2000 and later on our XP machine. The behavior is just the same: The pages show blank and time out after a long period. This happens in local and in remote. -- Edit this bug report at http://bugs.php.net/?id=25332&edit=1
#25331 [Opn->Bgs]: imagecreatefromstring() makes an error with some strings
ID: 25331 Updated by: [EMAIL PROTECTED] Reported By: hgshoggins at yahoo dot fr -Status: Open +Status: Bogus Bug Type: GD related Operating System: Linux web23.90.ha.ovh.net 2.4.20 PHP Version: 4.3.2 New Comment: And ask them to report bugs like this as they are the only ones able to really TEST any suggestions we might have. (if it works for you -> no bug anyway) Previous Comments: [2003-08-31 14:46:49] hgshoggins at yahoo dot fr Thanks Alot! I'll try to make them do this... Hoggins [2003-08-31 13:03:54] [EMAIL PROTECTED] Your ISP should really use the bundled version which is much more stable then the external library. If it works for you with the bundled library, then it's not a problem with PHP most likely. So you'll have to ask them to recompile PHP and use the bundled GD library. Derick [2003-08-31 12:53:36] hgshoggins at yahoo dot fr Description: hi, using a mysql db, and jpeg images strings in BLOB fields. All the images are readable on a computer through any image editor. But imagecreatefromstring() doesn't recognize some of them as valid jpeg strings, (it returns the classic error message "not a valid image string") and I couldn't be able to find the commom criteria of these images. The script is located on a server I do not own, and the admin says it's my script's fault. Some images work, and some not. The problem appeared since they went up to GD2. I'm only a PHP *USER*, so I do not use, and do not understand the compiling options, but I use the bundled gd2 library by uncommenting the line: "extension=php_gd2.dll". I test my scripts on a WinXP machine with Apache 2.0.45, and it perfectly works. I figured that, even if both my ISP and I are using GD2, it doesn't display the same way in phpinfo(): mine appears "bundled", and the ISP's doesn't. So I think the imagecreatefromstring() function doesn't accept some strings any more, which the previous version did on my ISP' servers. I hope that all the infos I provided will help you to solve the problem, which I'm sure doesn't come from me. Reproduce code: --- I just call a The script "script.php": (which normally contains the database connection infos, and the connection opening function) $sql="SELECT * FROM image_db WHERE id='$img_id'"; $resultat=mysql_query($sql); $quality=100; $ligne=mysql_fetch_array($resultat); $data=$ligne["data"]; $im=imagecreatefromstring($data); $im=imagejpeg($im,"",$quality); imageinterlace($im,$interlace); imagedestroy($im); Expected result: I whish it simply displayed *all* the images. It does for some, and doesn't for some others wich are -I think I repeat myself- perfectly readable otherwise. Actual result: -- Well, in fact it doesn't, and also displays an HTTP 500 Internal Server Error. I could get the error message only thanks to the admin, who tracked the error for me in a file. -- Edit this bug report at http://bugs.php.net/?id=25331&edit=1
#25333 [NEW]: symptom: mail() stripped chars from base64 data block
From: ap at d-dt dot de
Operating system: Windown XP
PHP version: 4.3.3
PHP Bug Type: Mail related
Bug description: symptom: mail() stripped chars from base64 data block
Description:
As of PHP 4.3.3 (Win) my mail class sends e-mails, which single stripped
characters. The same code worked with 4.3.2 (Win)
Used mailserver is Sendmail 8.12.6 on separate FreeBSD 5.1
Sending the message head and -body to stdout or apache produces a correct
Output, only the incoming results differs from the expected.
Reproduce code:
---
mail ($addressee, 'Subj: '.phpversion(),
chunk_split(base64_encode(file_get_contents('Images/numbers.zip'))),
$mime->head());
where $mime->head() are the MIME Headers. Two variants tested: using CRLF
and singe LF ("\r\n", "\n")
Expected result:
Incoming mail by 4.3.3 (incorrect, missing char in line 2: sequence is
.."Z8B5".., should by .."Z8HB5".. )...
6AZ0QAQoLzBw/GPw5JDx2LDgYDOHsFbMjAIWDj5xjZgHDEksh1tkNWwSNjg0
HmflkQthKJz4oIObx2ZVzMuLB9smqdh5vDixaVkTq6iTwZ8B5b59wu6aMgo
Jqa2cMuVTOI4mOjky82lu8HnRKMqMx+H9ZIYyalPmZeyal7hSWR0cmeXZWta
...
Incoming mail by 4.3.2
6AZ0QAQoLzBw/GPw5JDx2LDgYDOHsFbMjAIWDj5xjZgHDEksh1tkNWwSNjg0
HmflkQthKJz4oIObx2ZVzMuLB9smqdh5vDixaVkTq6iTwZ8HB5b59wu6aMgo
Jqa2cMuVTOI4mOjky82lu8HnRKMqMx+H9ZIYyalPmZeyal7hSWR0cmeXZWta
..
--
Edit bug report at http://bugs.php.net/?id=25333&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25333&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25333&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25333&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25333&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25333&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25333&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25333&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25333&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25333&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25333&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25333&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25333&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25333&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25333&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25333&r=gnused
#25296 [Opn->Fbk]: error on ftp_nlist
ID: 25296 Updated by: [EMAIL PROTECTED] Reported By: ates at isikun dot edu dot tr -Status: Open +Status: Feedback Bug Type: FTP related Operating System: win xp PHP Version: 4.3.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-08-28 10:44:41] ates at isikun dot edu dot tr look at url = http://webgroup.isikun.edu.tr/arge/ftp/ftp_connect.php and the basic code to show you the error : (file is /tosun.txt) //here code starts $ftp_server2 = "webgroup.isikun.edu.tr"; $ftp_user_name = "ates"; $ftp_user_pass = "*"; $conn = ftp_connect($ftp_server2,5000); ftp_login($conn, $ftp_user_name, $ftp_user_pass); $nlist = (ftp_nlist($conn, "/tosun.txt")); $rawlist = ftp_rawlist($conn, "/tosun.txt"); echo "nlist=>"; print_r($nlist); echo "rawlist=>"; print_r($rawlist); ftp_close($conn); [2003-08-28 10:06:58] [EMAIL PROTECTED] Cannot reproduce. Based on the description you provided I get the results which are expected from the documentation of ftp_nlist(). Please provide a simple and COMPLETE script which reproduces this error. Obviously nooone expects you to give out a password to your own server, but you could try to reproduce this on a public ftp server. [2003-08-28 09:53:16] ates at isikun dot edu dot tr Description: when i use $array=ftp_nlist(exact file name) // for example ftp_nlist(/http/fopen.php) it returns /http/fopen.php/fopen.php as 1st element of array so it must return /http/fopen.php .. -- Edit this bug report at http://bugs.php.net/?id=25296&edit=1
#25294 [Opn->Fbk]: ftp_nlist fails on nai site with coredump
ID: 25294 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Linux 2.4.21 PHP Version: 4.3.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-08-29 03:16:48] steveh at brendata dot co dot uk Ok, it failed as before, here's the output: (gdb) run test.php Starting program: /usr/src/php-4.3.3/sapi/cli/php test.php resource(4) of type (FTP Buffer) resource(4) of type (FTP Buffer) bool(false) resource(4) of type (FTP Buffer) [Fri Aug 29 09:04:06 2003] Script: 'test.php' --- /usr/src/php-4.3.3/ext/ftp/ftp.c(1443) : Block 0x081EF888 status: Beginning: Overrun (magic=0x401E0470, expected=0x7312F8DC) End: Unknown --- Program exited normally. (gdb) [2003-08-28 19:48:11] [EMAIL PROTECTED] Try the following: # rm config.cache # ./configure --disable-all --disable-cgi --enable-ftp --enable-debug # make clean && make And then run the script: # gdb sapi/cli/php (gdb) run ftptest.php . . [2003-08-28 11:19:11] steveh at brendata dot co dot uk Just realised, one thing I haven't mentioned (!) is that I'm running this as a command line script (php test.php). Here's the backtrace (looks like it's when it's trying to deallocate stuff) (gdb) bt #0 0x403a9490 in chunk_free (ar_ptr=0x4045d300, p=0x830ba58) at malloc.c:3231 #1 0x403a93f4 in __libc_free (mem=0x830baa8) at malloc.c:3154 #2 0x08175fb4 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/src/php-4.3.3/Zend/zend_alloc.c:492 #3 0x0815be20 in php_request_shutdown (dummy=0x0) at /usr/src/php-4.3.3/main/main.c:1005 #4 0x081a6c61 in main (argc=2, argv=0xbbe4) at /usr/src/php-4.3.3/sapi/cli/php_cli.c:869 #5 0x40344657 in __libc_start_main (main=0x81a61fc , argc=2, ubp_av=0xbbe4, init=0x8072174 <_init>, fini=0x81ac480 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbbdc) at ../sysdeps/generic/libc-start.c:129 [2003-08-28 11:15:57] steveh at brendata dot co dot uk Looks like it's dying after the dump: [EMAIL PROTECTED] /root]# php test.php resource(4) of type (FTP Buffer) resource(4) of type (FTP Buffer) bool(false) resource(4) of type (FTP Buffer) Segmentation fault (core dumped) [EMAIL PROTECTED] /root]# cat test.php Here's the ./configure: ./configure i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir= /usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --ma ndir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc --enable-force-cgi-redirect --enable-debug- -enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db3 --with-exec-dir=/usr/bin --with-png-dir=/usr --with-g d --enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext --with-ncurses --with-gmp --with-iconv --with-jpeg-dir=/usr --with-op enssl --with-png --with-pspell --with-regex=system --with-ftp --with-zlib --with-layout=GNU --enable-bcmath --enable-debugger --enab le-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --en able-trans-sid --enable-yp --enable-wddx --without-oci8 --with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos --with-ldap =shared --with-mysql=shared,/usr --with-xml --with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=shared --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning --enablecalendar --enable-dbx --enable-dio --enable-mbstring --enable-mbstr-enc-trans --withapxs=/usr/sbin/apxs --with-sybasect=shared,/usr/local/freetds --enable-ftp [2003-08-28 11:02:49] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, ple
#25331 [Fbk->Opn]: imagecreatefromstring() makes an error with some strings
ID: 25331 User updated by: hgshoggins at yahoo dot fr Reported By: hgshoggins at yahoo dot fr -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux web23.90.ha.ovh.net 2.4.20 PHP Version: 4.3.2 New Comment: Thanks Alot! I'll try to make them do this... Hoggins Previous Comments: [2003-08-31 13:03:54] [EMAIL PROTECTED] Your ISP should really use the bundled version which is much more stable then the external library. If it works for you with the bundled library, then it's not a problem with PHP most likely. So you'll have to ask them to recompile PHP and use the bundled GD library. Derick [2003-08-31 12:53:36] hgshoggins at yahoo dot fr Description: hi, using a mysql db, and jpeg images strings in BLOB fields. All the images are readable on a computer through any image editor. But imagecreatefromstring() doesn't recognize some of them as valid jpeg strings, (it returns the classic error message "not a valid image string") and I couldn't be able to find the commom criteria of these images. The script is located on a server I do not own, and the admin says it's my script's fault. Some images work, and some not. The problem appeared since they went up to GD2. I'm only a PHP *USER*, so I do not use, and do not understand the compiling options, but I use the bundled gd2 library by uncommenting the line: "extension=php_gd2.dll". I test my scripts on a WinXP machine with Apache 2.0.45, and it perfectly works. I figured that, even if both my ISP and I are using GD2, it doesn't display the same way in phpinfo(): mine appears "bundled", and the ISP's doesn't. So I think the imagecreatefromstring() function doesn't accept some strings any more, which the previous version did on my ISP' servers. I hope that all the infos I provided will help you to solve the problem, which I'm sure doesn't come from me. Reproduce code: --- I just call a The script "script.php": (which normally contains the database connection infos, and the connection opening function) $sql="SELECT * FROM image_db WHERE id='$img_id'"; $resultat=mysql_query($sql); $quality=100; $ligne=mysql_fetch_array($resultat); $data=$ligne["data"]; $im=imagecreatefromstring($data); $im=imagejpeg($im,"",$quality); imageinterlace($im,$interlace); imagedestroy($im); Expected result: I whish it simply displayed *all* the images. It does for some, and doesn't for some others wich are -I think I repeat myself- perfectly readable otherwise. Actual result: -- Well, in fact it doesn't, and also displays an HTTP 500 Internal Server Error. I could get the error message only thanks to the admin, who tracked the error for me in a file. -- Edit this bug report at http://bugs.php.net/?id=25331&edit=1
#25332 [NEW]: Update from 4.3.2 to 4.3.3 won't work
From: info at y2ksw dot it Operating system: Windows XP Pro/ Win 2000 server PHP version: 4.3.3 PHP Bug Type: Unknown/Other Function Bug description: Update from 4.3.2 to 4.3.3 won't work Description: We tried today to make an update and our PHP applications don't work any more. Uninstalling and downgrading to 4.3.2 works perfectly well. We tried first on our win 2000 and later on our XP machine. The behavior is just the same: The pages show blank and time out after a long period. This happens in local and in remote. -- Edit bug report at http://bugs.php.net/?id=25332&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25332&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25332&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25332&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25332&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25332&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25332&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25332&r=support Expected behavior: http://bugs.php.net/fix.php?id=25332&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25332&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25332&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25332&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25332&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25332&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25332&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25332&r=gnused
#25331 [Opn->Fbk]: imagecreatefromstring() makes an error with some strings
ID: 25331 Updated by: [EMAIL PROTECTED] Reported By: hgshoggins at yahoo dot fr -Status: Open +Status: Feedback Bug Type: GD related Operating System: Linux web23.90.ha.ovh.net 2.4.20 PHP Version: 4.3.2 New Comment: Your ISP should really use the bundled version which is much more stable then the external library. If it works for you with the bundled library, then it's not a problem with PHP most likely. So you'll have to ask them to recompile PHP and use the bundled GD library. Derick Previous Comments: [2003-08-31 12:53:36] hgshoggins at yahoo dot fr Description: hi, using a mysql db, and jpeg images strings in BLOB fields. All the images are readable on a computer through any image editor. But imagecreatefromstring() doesn't recognize some of them as valid jpeg strings, (it returns the classic error message "not a valid image string") and I couldn't be able to find the commom criteria of these images. The script is located on a server I do not own, and the admin says it's my script's fault. Some images work, and some not. The problem appeared since they went up to GD2. I'm only a PHP *USER*, so I do not use, and do not understand the compiling options, but I use the bundled gd2 library by uncommenting the line: "extension=php_gd2.dll". I test my scripts on a WinXP machine with Apache 2.0.45, and it perfectly works. I figured that, even if both my ISP and I are using GD2, it doesn't display the same way in phpinfo(): mine appears "bundled", and the ISP's doesn't. So I think the imagecreatefromstring() function doesn't accept some strings any more, which the previous version did on my ISP' servers. I hope that all the infos I provided will help you to solve the problem, which I'm sure doesn't come from me. Reproduce code: --- I just call a The script "script.php": (which normally contains the database connection infos, and the connection opening function) $sql="SELECT * FROM image_db WHERE id='$img_id'"; $resultat=mysql_query($sql); $quality=100; $ligne=mysql_fetch_array($resultat); $data=$ligne["data"]; $im=imagecreatefromstring($data); $im=imagejpeg($im,"",$quality); imageinterlace($im,$interlace); imagedestroy($im); Expected result: I whish it simply displayed *all* the images. It does for some, and doesn't for some others wich are -I think I repeat myself- perfectly readable otherwise. Actual result: -- Well, in fact it doesn't, and also displays an HTTP 500 Internal Server Error. I could get the error message only thanks to the admin, who tracked the error for me in a file. -- Edit this bug report at http://bugs.php.net/?id=25331&edit=1
#25331 [NEW]: imagecreatefromstring() makes an error with some strings
From: hgshoggins at yahoo dot fr Operating system: Linux web23.90.ha.ovh.net 2.4.20 PHP version: 4.3.2 PHP Bug Type: GD related Bug description: imagecreatefromstring() makes an error with some strings Description: hi, using a mysql db, and jpeg images strings in BLOB fields. All the images are readable on a computer through any image editor. But imagecreatefromstring() doesn't recognize some of them as valid jpeg strings, (it returns the classic error message "not a valid image string") and I couldn't be able to find the commom criteria of these images. The script is located on a server I do not own, and the admin says it's my script's fault. Some images work, and some not. The problem appeared since they went up to GD2. I'm only a PHP *USER*, so I do not use, and do not understand the compiling options, but I use the bundled gd2 library by uncommenting the line: "extension=php_gd2.dll". I test my scripts on a WinXP machine with Apache 2.0.45, and it perfectly works. I figured that, even if both my ISP and I are using GD2, it doesn't display the same way in phpinfo(): mine appears "bundled", and the ISP's doesn't. So I think the imagecreatefromstring() function doesn't accept some strings any more, which the previous version did on my ISP' servers. I hope that all the infos I provided will help you to solve the problem, which I'm sure doesn't come from me. Reproduce code: --- I just call a The script "script.php": (which normally contains the database connection infos, and the connection opening function) $sql="SELECT * FROM image_db WHERE id='$img_id'"; $resultat=mysql_query($sql); $quality=100; $ligne=mysql_fetch_array($resultat); $data=$ligne["data"]; $im=imagecreatefromstring($data); $im=imagejpeg($im,"",$quality); imageinterlace($im,$interlace); imagedestroy($im); Expected result: I whish it simply displayed *all* the images. It does for some, and doesn't for some others wich are -I think I repeat myself- perfectly readable otherwise. Actual result: -- Well, in fact it doesn't, and also displays an HTTP 500 Internal Server Error. I could get the error message only thanks to the admin, who tracked the error for me in a file. -- Edit bug report at http://bugs.php.net/?id=25331&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25331&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25331&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25331&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25331&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25331&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25331&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25331&r=support Expected behavior: http://bugs.php.net/fix.php?id=25331&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25331&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25331&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25331&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25331&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25331&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25331&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25331&r=gnused
#25329 [Opn->Ver]: sqlite_create_function cant call method of $this as function kills apache(2)
ID: 25329
Updated by: [EMAIL PROTECTED]
Reported By: firepages at firepages dot com dot au
-Status: Open
+Status: Verified
Bug Type: SQLite related
Operating System: win XP
-PHP Version: 4.3.3
+PHP Version: 5.0.0b2-dev, 4.3.3
New Comment:
PECL_4_3:
/usr/src/web/php/php4_3/Zend/zend_hash.c(544) : ht=0x08212634 is being
destroyed
/usr/src/web/php/php4_3/Zend/zend_hash.c(108) : Bailed out without a
bailout address!
HEAD:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
_efree (ptr=0x0) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
257 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0 _efree (ptr=0x0) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
#1 0x816cdfb in _zval_ptr_dtor (zval_ptr=0x4029bac4) at
/usr/src/web/php/php5/Zend/zend_execute.h:67
#2 0x80b80c2 in php_sqlite_callback_invalidator (funcs=0x4029babc) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:288
#3 0x80b8110 in php_sqlite_callback_dtor (pDest=0x4029babc) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:310
#4 0x817a738 in zend_hash_destroy (ht=0x4029b8ec) at
/usr/src/web/php/php5/Zend/zend_hash.c:513
#5 0x80b813c in php_sqlite_db_dtor (rsrc=0x4029b95c) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:321
#6 0x817bb4d in list_entry_destructor (ptr=0x4029b95c) at
/usr/src/web/php/php5/Zend/zend_list.c:178
#7 0x817a89e in zend_hash_apply_deleter (ht=0x8349f10, p=0x4029b924)
at /usr/src/web/php/php5/Zend/zend_hash.c:568
#8 0x817a9da in zend_hash_graceful_reverse_destroy (ht=0x8349f10) at
/usr/src/web/php/php5/Zend/zend_hash.c:634
#9 0x817bc56 in zend_destroy_rsrc_list (ht=0x8349f10) at
/usr/src/web/php/php5/Zend/zend_list.c:234
#10 0x816cc93 in shutdown_executor () at
/usr/src/web/php/php5/Zend/zend_execute_API.c:279
#11 0x817555f in zend_deactivate () at
/usr/src/web/php/php5/Zend/zend.c:795
#12 0x8149224 in php_request_shutdown (dummy=0x0) at
/usr/src/web/php/php5/main/main.c:1197
#13 0x81ab61e in main (argc=2, argv=0xb694) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:1013
#14 0x401b19cb in __libc_start_main (main=0x81aa848 , argc=2,
argv=0xb694, init=0x8070368 <_init>,
fini=0x81abbe4 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xb68c)
at ../sysdeps/generic/libc-start.c:92
Previous Comments:
[2003-08-31 00:00:32] firepages at firepages dot com dot au
Description:
when trying to use sqlite_create_function() & passing a class method of
$this apache dies orribly (appreciate it may be an apache issue)
Win XP Pro / php 4.3.3 compiled (MSVC) against apache 2.0.47
eg
sqlite_create_function($this->db, 'link_keywords', array(
$this,'linkers' ) , 1);
/*OR*/
sqlite_create_function($this->db, 'link_keywords', array(
&$this,'linkers' ) , 1);
note that calling an external class method or normal function
[array($ext_class,$method)]gives no problem , just methods of $this
not tested on apache 1.*
Reproduce code:
---
class sqlite_help{
function sqlite_help(){
$this->db = sqlite_open('e:/phpdev/cp/my_admin.sqldb.eng', 0666,
$sqliteerror);
sqlite_create_function($this->db, 'link_keywords', array( $this ,
'linkers') , 1);
return $this->db;
}
function get_single( $key ){
$res = sqlite_query( $this->db,"SELECT link_keywords(var) FROM
my_admin WHERE key = '$key'" );
$r = sqlite_fetch_array( $res , SQLITE_NUM );
return $r[0];
}
function linkers( $str ){
$keywords = array('phpmyadmin'=>'http://localhost/phpmyadmin/index.php"";>phpMyAdmin');
foreach($keywords as $k=>$v){$str = str_replace( $k , $v , $str );}
return nl2br( $str );
}
}
$yaks=new sqlite_help();
echo $yaks->get_single('general');
Expected result:
str_replaced data from DB
works if function is external or external class method
Actual result:
--
an MS 'Apache has encountered an ' etc Dialog no apache error log
available , no PHP error logged.
--
Edit this bug report at http://bugs.php.net/?id=25329&edit=1
#25328 [Opn->Bgs]: modulus operator problem with large numbers
ID: 25328
Updated by: [EMAIL PROTECTED]
Reported By: hakon at haugnes dot name
-Status: Open
+Status: Bogus
Bug Type: *Math Functions
Operating System: Redhat 8.0
PHP Version: 4.3.2
New Comment:
It's not a malfunction, PHP simply doesn't support integer numbers over
2^31 - 1 and will convert them to a float. And yes, you should use the
bc* functions for this.
Derick
Previous Comments:
[2003-08-30 19:06:09] hakon at haugnes dot name
I just realized that the [mal]functioning of % for large numbers is
probably why the function BCMOD has been created...
[2003-08-30 18:39:00] hakon at haugnes dot name
Description:
The modulus operator % returns wrong results if the number gets large.
In a program used to calculate primes, it will find that large numbers,
ending in 5, are prime. The following are calculations using % on such
a large number, note that all numbers used in the MOD calculation are
whole integers (and should not suffer rounding by MOD):
MOD: 53253252355 % 3=1
DIV: 53253252355 / 3=17751084118.32061767578125
MOD: 53253252355 % 4=3
DIV: 53253252355 / 4=13313313088.75
MOD: 53253252355 % 5=2
DIV: 53253252355 / 5=10650650471
Obviously, any number ending in 5 cannot be prime, since it will always
be divisible by 5. The MOD result on 5 is therefore wrong, as the
division proves.
Reproduce code:
---
$i=53253252355;
ini_set("precision",35);
for ($m=2; $m<=$i; $m++){
echo "MOD: $i % $m=". $i % $m ;
echo "DIV: $i / $m=". $i/$m ."";
}
Expected result:
I would expect to see
MOD: 53253252355 % 3=1
DIV: 53253252355 / 3=17751084118.32061767578125
MOD: 53253252355 % 4=3
DIV: 53253252355 / 4=13313313088.75
MOD: 53253252355 % 5=0
DIV: 53253252355 / 5=10650650471
Actual result:
--
However, this is produced: ([THE ERROR] added for your convenience)
MOD: 53253252355 % 3=1
DIV: 53253252355 / 3=17751084118.32061767578125
MOD: 53253252355 % 4=3
DIV: 53253252355 / 4=13313313088.75
MOD: 53253252355 % 5=2 [THE ERROR]
DIV: 53253252355 / 5=10650650471
--
Edit this bug report at http://bugs.php.net/?id=25328&edit=1
#25329 [NEW]: sqlite_create_function cant call method of $this as function kills apache(2)
From: firepages at firepages dot com dot au
Operating system: win XP
PHP version: 4.3.3
PHP Bug Type: SQLite related
Bug description: sqlite_create_function cant call method of $this as function kills
apache(2)
Description:
when trying to use sqlite_create_function() & passing a class method of
$this apache dies orribly (appreciate it may be an apache issue)
Win XP Pro / php 4.3.3 compiled (MSVC) against apache 2.0.47
eg
sqlite_create_function($this->db, 'link_keywords', array( $this,'linkers'
) , 1);
/*OR*/
sqlite_create_function($this->db, 'link_keywords', array( &$this,'linkers'
) , 1);
note that calling an external class method or normal function
[array($ext_class,$method)]gives no problem , just methods of $this
not tested on apache 1.*
Reproduce code:
---
class sqlite_help{
function sqlite_help(){
$this->db = sqlite_open('e:/phpdev/cp/my_admin.sqldb.eng', 0666,
$sqliteerror);
sqlite_create_function($this->db, 'link_keywords', array( $this ,
'linkers') , 1);
return $this->db;
}
function get_single( $key ){
$res = sqlite_query( $this->db,"SELECT link_keywords(var) FROM my_admin
WHERE key = '$key'" );
$r = sqlite_fetch_array( $res , SQLITE_NUM );
return $r[0];
}
function linkers( $str ){
$keywords = array('phpmyadmin'=>'http://localhost/phpmyadmin/index.php"";>phpMyAdmin');
foreach($keywords as $k=>$v){$str = str_replace( $k , $v , $str );}
return nl2br( $str );
}
}
$yaks=new sqlite_help();
echo $yaks->get_single('general');
Expected result:
str_replaced data from DB
works if function is external or external class method
Actual result:
--
an MS 'Apache has encountered an ' etc Dialog no apache error log
available , no PHP error logged.
--
Edit bug report at http://bugs.php.net/?id=25329&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25329&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25329&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25329&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25329&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25329&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25329&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25329&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25329&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25329&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25329&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25329&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25329&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25329&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25329&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25329&r=gnused
#25325 [Opn->Csd]: command from exec do not migrate in an openMosix cluster
ID: 25325
User updated by: carb at videotron dot ca
Reported By: carb at videotron dot ca
-Status: Open
+Status: Closed
Bug Type: Filesystem function related
Operating System: RedHat 9.0
PHP Version: 4.3.3
New Comment:
Running the command with "mosrun -l" removes the lock so that it can
migrate.
/dev/null 2>&1 &");
?>
Previous Comments:
[2003-08-30 18:35:21] carb at videotron dot ca
Hi, Thank you for your responses. I fully understand that you do not
work with openMosix.
Yes, there is a cantmove file, but it is empty, meaning that
But is an important issue for anyone who plans to develop a PHP website
that can start processes on an openMosix or any other SSI type cluster.
Since any process that will come fomr php will never migrate, php
could not be used as a front end.
So it would be fun to try to solve this and I am certain that the
openMosix side will also help look at it.
The root of the problem is probably related to the additional stuff
being added to the process when it comes from PHP. Do you have an idea
what this additional (approx.) 600K is?
Yes, the cantmove file is present for all the processes but
unfortunately there are no error messages in it for the processes that
don't migrate.
I will experiment with popen to see if I get different results.
Thanks in advance,
Real
[2003-08-30 17:59:28] [EMAIL PROTECTED]
I don't know openMosix at all (first heard about it now :),
but I read this:
http://howto.ipng.be/openMosix-HOWTO/x1225.html
That first column, about "/proc/$pid/, there often is a cantmove
file..", have you checked that?
Also you should know that we don't fork() with exec() function.
(proc_open() does, maybe you should use that instead?)
[2003-08-30 16:51:51] carb at videotron dot ca
I think it is related to PHP because that exact command get migrated
correctly when executed from the command line, but does not when it is
executed from PHP/exec().
When starting the process from the command line, the process sizes
are:
SIZE:128, RSS:128, SHARE:40 and it migrates.
When starting the process from PHP/Apache, the process sizes are:
SIZE:736, RSS:732, SHARE:652 and it does NOT migrate.
When starting the process from PHP at the command line, the process
sizes are:
SIZE:740, RSS:732, SHARE:652 and it does NOT migrate.
So we can see that there is alot of extra stuff comming from PHP that
is in the process and it would be this that is affecting the
migration.
openMosix cannot migrate processes that have shared memory, there may
be something like that coming from comming from PHP.
I also posted a message to the openMosix group in case they can help.
https://sourceforge.net/tracker/index.php?func=detail&aid=797919&group_id=46729&atid=447171
Thanks in advance,
Real
[2003-08-30 16:12:41] [EMAIL PROTECTED]
Why do you think this is related to PHP? PHP does *nothing* special
with processes... I wonder how this can be related to OpenMosix.
[2003-08-30 16:05:16] carb at videotron dot ca
Description:
executing a command from PHP, the command does not get migrated in an
openMosix cluster, even if the command migrates when it is executed
from the command line.
Running "awk 'BEGIN {for(i=0;i<1;i++)for(j=0;j<1;j++);}' >
/dev/null 2>&1 &" from a command line several times creates processes
that get migrated.
Running the same thing several times from an exec in a PHP script does
not get migrated.
The same problem occurs whether the script is executed from apache
"http://localhost/test.php/"; or the command line "php test.php"
Reproduce code:
---
/dev/null 2>&1 &");
?>
Expected result:
When executing the script several times in an openMosix cluster, some
of the processes should migrate.
Actual result:
--
When executing the script several times in an openMosix cluster, none
of the processes migrate.
--
Edit this bug report at http://bugs.php.net/?id=25325&edit=1
#25328 [Opn]: modulus operator problem with large numbers
ID: 25328
User updated by: hakon at haugnes dot name
Reported By: hakon at haugnes dot name
Status: Open
Bug Type: *Math Functions
Operating System: Redhat 8.0
PHP Version: 4.3.2
New Comment:
I just realized that the [mal]functioning of % for large numbers is
probably why the function BCMOD has been created...
Previous Comments:
[2003-08-30 18:39:00] hakon at haugnes dot name
Description:
The modulus operator % returns wrong results if the number gets large.
In a program used to calculate primes, it will find that large numbers,
ending in 5, are prime. The following are calculations using % on such
a large number, note that all numbers used in the MOD calculation are
whole integers (and should not suffer rounding by MOD):
MOD: 53253252355 % 3=1
DIV: 53253252355 / 3=17751084118.32061767578125
MOD: 53253252355 % 4=3
DIV: 53253252355 / 4=13313313088.75
MOD: 53253252355 % 5=2
DIV: 53253252355 / 5=10650650471
Obviously, any number ending in 5 cannot be prime, since it will always
be divisible by 5. The MOD result on 5 is therefore wrong, as the
division proves.
Reproduce code:
---
$i=53253252355;
ini_set("precision",35);
for ($m=2; $m<=$i; $m++){
echo "MOD: $i % $m=". $i % $m ;
echo "DIV: $i / $m=". $i/$m ."";
}
Expected result:
I would expect to see
MOD: 53253252355 % 3=1
DIV: 53253252355 / 3=17751084118.32061767578125
MOD: 53253252355 % 4=3
DIV: 53253252355 / 4=13313313088.75
MOD: 53253252355 % 5=0
DIV: 53253252355 / 5=10650650471
Actual result:
--
However, this is produced: ([THE ERROR] added for your convenience)
MOD: 53253252355 % 3=1
DIV: 53253252355 / 3=17751084118.32061767578125
MOD: 53253252355 % 4=3
DIV: 53253252355 / 4=13313313088.75
MOD: 53253252355 % 5=2 [THE ERROR]
DIV: 53253252355 / 5=10650650471
--
Edit this bug report at http://bugs.php.net/?id=25328&edit=1
