#45188 [NoF-Csd]: Crash during request shutdown if mail server shuts down
ID: 45188 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com -Status: No Feedback +Status: Closed Bug Type: IMAP related Operating System: linux PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: I was now able to verify that the issue does not occur with PHP 5.2.x 200906030630 anymore. Case closed :-) Previous Comments: [2009-05-27 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-05-19 15:24:10] j...@php.net Now, since you could fix the compile failure, does your original issue in this report exist or not using that snapshot? (we'll deal with that compile failure, don't worrry :) [2008-06-05 15:41:29] thomas dot jarosch at intra2net dot com Description: Hello together, if you use a webmail applications like Horde's IMP and restart the server while an IMAP command is processing, PHP segfaults on request shutdown. Here's a backtrace of the crash: (gdb) bt #0 0x632f6564 in ?? () #1 0x01a6b575 in mail_close_full (stream=0x87b8ad8, options=0) at mail.c:1361 #2 0x01a494e3 in mail_close_it (rsrc=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/ext/imap/php_imap.c:229 #3 0x006dacc7 in list_entry_destructor (ptr=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:184 #4 0x006d8a3a in zend_hash_del_key_or_index (ht=0x7cb480, arKey=0x0, nKeyLength=0, h=81, flag=1) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:497 #5 0x006da915 in _zend_list_delete (id=81) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:58 #6 0x006cb9ed in _zval_dtor_func (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.c:60 #7 0x006be95e in _zval_dtor (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.h:35 #8 0x006bebac in _zval_ptr_dtor (zval_ptr=0xb79a9610) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:414 #9 0x006d8b33 in zend_hash_destroy (ht=0xb7a1a71c) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:526 #10 0x006eae64 in zend_object_std_dtor (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:45 #11 0x006eb287 in zend_objects_free_object_storage (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:122 #12 0x006eec3f in zend_objects_store_free_object_storage (objects=0x7cb528) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects_API.c:89 #13 0x006be7c7 in shutdown_executor () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:299 #14 0x006cd48d in zend_deactivate () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend.c:860 #15 0x0067d8d2 in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-5.2.6/main/main.c:1486 #16 0x00742f2f in php_apache_request_dtor (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:469 #17 0x007438ce in php_handler (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:641 #18 0x08065f19 in ap_run_handler () #19 0x08068f61 in ap_invoke_handler () #20 0x080639d8 in ap_process_request () #21 0x0805e6b8 in _start () I took a look at the structures in #1 mail_close_full (stream=0x87b8ad8, options=0), the memory was totally bogus and already reused. To me this looks like a use-after-free issue. While debugging I've found another crash in c-client's IMAP extension and I will submit a patch upstream. I was unable to find the source of this crash, but I suspect the connection already gets closed and then PHP tries to close it twice or something like that. Reproduce code: --- Move mails via IMAP to another folder and restart your IMAP server. Expected result: Error message Connection to server died. Actual result: -- Segfault. -- Edit this bug report at http://bugs.php.net/?id=45188edit=1
#45188 [NoF-Opn]: Crash during request shutdown if mail server shuts down
ID: 45188
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
-Status: No Feedback
+Status: Open
Bug Type: IMAP related
Operating System: linux
PHP Version: 5.2.6
Assigned To: fb-req-jani
New Comment:
Hi,
I can compile the snapshot on my Fedora 9 workstation using gcc
4.3.0. The build of the snapshot fails on my devel box using gcc
4.3.2 + ancient glibc version. Here's the error message I get:
In file included from /tmp/php-5.2.10/Zend/zend.h:236,
from /tmp/php-5.2.10/main/php.h:34,
from /tmp/php-5.2.10/ext/date/php_date.c:23:
/tmp/php-5.2.10/Zend/zend_alloc.h:34: error: expected specifier-
I tracked it down to this code snippet:
[r...@intradev /tmp]# cat main.c
#define _ISOC9X_SOURCE
#include sys/types.h
typedef struct _zend_leak_info {
// void *addr;
// size_t size;
// char *filename;
uint lineno;
// char *orig_filename;
// uint orig_lineno;
} zend_leak_info;
int main(void)
{
return 0;
}
[r...@intradev /tmp]# gcc main.c
main.c:9: error: expected specifier-qualifier-list before 'uint'
[r...@intradev /tmp]# gcc --version
gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6)
If I remove the #define _ISOC9X_SOURCE, it compiles fine,
same thing for ext/date/php_date.c.
The corresponding commit is here:
http://cvs.php.net:80/viewvc.cgi/php-
and
http://cvs.php.net:80/viewvc.cgi/php-
Is the _ISOC9X_SOURCE define really needed?
Previous Comments:
[2009-05-12 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-05-04 13:24:46] thomas dot jarosch at intra2net dot com
Thanks for checking. I'll test again this week and report back.
[2009-04-30 09:40:13] j...@php.net
Compiles fine for me. Try again with latest snapshot. (make sure to
unpack and build in clean dirs..)
[2009-04-29 14:27:02] thomas dot jarosch at intra2net dot com
Is the latest snapshot compilable?
I get this:
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:129:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'stream_cookie_functions'
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c: In
function '_php_stream_cast':
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
error: 'stream_cookie_functions' undeclared (first use in this
function)
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
error: (Each undeclared identifier is reported only once
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
error: for each function it appears in.)
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
warning: assignment makes pointer from integer without a cast
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:221:
warning: passing argument 3 of '_php_stream_cast' makes pointer from
integer without a cast
[2009-04-27 19:14:40] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/45188
--
Edit this bug report at http://bugs.php.net/?id=45188edit=1
#45188 [Opn]: Crash during request shutdown if mail server shuts down
ID: 45188
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
Status: Open
Bug Type: IMAP related
Operating System: linux
PHP Version: 5.2.6
Assigned To: fb-req-jani
New Comment:
Is it just me or this some information go missing
while posting in the bug tracker??
Anyway, the error message is:
/tmp/php-5.2.10/Zend/zend_alloc.h:34: error: expected
specifier-qualifier-list before 'uint'
Previous Comments:
[2009-05-18 09:23:24] thomas dot jarosch at intra2net dot com
Hi,
I can compile the snapshot on my Fedora 9 workstation using gcc
4.3.0. The build of the snapshot fails on my devel box using gcc
4.3.2 + ancient glibc version. Here's the error message I get:
In file included from /tmp/php-5.2.10/Zend/zend.h:236,
from /tmp/php-5.2.10/main/php.h:34,
from /tmp/php-5.2.10/ext/date/php_date.c:23:
/tmp/php-5.2.10/Zend/zend_alloc.h:34: error: expected specifier-
I tracked it down to this code snippet:
[r...@intradev /tmp]# cat main.c
#define _ISOC9X_SOURCE
#include sys/types.h
typedef struct _zend_leak_info {
// void *addr;
// size_t size;
// char *filename;
uint lineno;
// char *orig_filename;
// uint orig_lineno;
} zend_leak_info;
int main(void)
{
return 0;
}
[r...@intradev /tmp]# gcc main.c
main.c:9: error: expected specifier-qualifier-list before 'uint'
[r...@intradev /tmp]# gcc --version
gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6)
If I remove the #define _ISOC9X_SOURCE, it compiles fine,
same thing for ext/date/php_date.c.
The corresponding commit is here:
http://cvs.php.net:80/viewvc.cgi/php-
and
http://cvs.php.net:80/viewvc.cgi/php-
Is the _ISOC9X_SOURCE define really needed?
[2009-05-12 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-05-04 13:24:46] thomas dot jarosch at intra2net dot com
Thanks for checking. I'll test again this week and report back.
[2009-04-30 09:40:13] j...@php.net
Compiles fine for me. Try again with latest snapshot. (make sure to
unpack and build in clean dirs..)
[2009-04-29 14:27:02] thomas dot jarosch at intra2net dot com
Is the latest snapshot compilable?
I get this:
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:129:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'stream_cookie_functions'
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c: In
function '_php_stream_cast':
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
error: 'stream_cookie_functions' undeclared (first use in this
function)
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
error: (Each undeclared identifier is reported only once
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
error: for each function it appears in.)
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181:
warning: assignment makes pointer from integer without a cast
/usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:221:
warning: passing argument 3 of '_php_stream_cast' makes pointer from
integer without a cast
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/45188
--
Edit this bug report at http://bugs.php.net/?id=45188edit=1
#45213 [Ver-Csd]: imap_utf7_encode() computes wrong UTF-7 data
ID: 45213 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com -Status: Verified +Status: Closed Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-04-27) New Comment: Sounds good. Thanks! Previous Comments: [2009-05-02 18:03:40] paj...@php.net I added imap_utf8_to_mutf7 and imap_mutf7_to_utf8 to php 5.3 and 6.0. 5.2 can't accept new features, you can easily backport the two functions from 5.3. However I won't fix the utf7_encode/decode functions as they should actually use the imap API and UTF-8. [2009-04-28 07:53:49] thomas dot jarosch at intra2net dot com As far as I know, iconv does not support IMAP modified UTF7 out of the box. Atleast my version 1.9.1 does not and I have a patch for exactly that. Though we can't rely on people having a patched iconv version. The c-client IMAP library has support for UTF8 - modified UTF7. Maybe that would be an option? [2009-04-27 20:31:15] paj...@php.net Should we not simply rely on iconv in 5.2/5.3 and ICU in HEAD? [2009-04-27 19:07:23] j...@php.net Here is short and reliable test: # sapi/cli/php -r '$tst = mb_convert_encoding(täst, ISO-8859-1, UTF8); echo $tst, \n; echo imap_utf7_encode($tst), \n, mb_convert_encoding($tst, UTF7-IMAP, ISO-8859-1), \n;' [2008-06-09 13:17:53] thomas dot jarosch at intra2net dot com Description: Hello together, I tried to encode german umlauts using imap_utf7_encode(), but the computed string is not understood by the cyrus IMAP server. This is pretty much related to bug #15630, but now I had the help of a coworker who is pretty fast decoding base64 by hand :-) UTF-7 is defined to encode special characters as two byte UTF-16 stream. Normally the ISO-8859-1 string täst should be encoded into tAOQ-st, which corresponds to 0x00, 0xe4. The current code in PHP 5.2.6 encodes it to t5A-st, which is 0xe4 without the leading 0x00. Would be nice if that could be resolved since it's not compatible with most IMAP implementations. Bug #15630 is around since 2002. Cheers, Thomas Reproduce code: --- echo imap_utf7_encode(täst); Expected result: tAOQ-st Actual result: -- t5A-st -- Edit this bug report at http://bugs.php.net/?id=45213edit=1
#45188 [Fbk-Opn]: Crash during request shutdown if mail server shuts down
ID: 45188 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: linux PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: Thanks for checking. I'll test again this week and report back. Previous Comments: [2009-04-30 09:40:13] j...@php.net Compiles fine for me. Try again with latest snapshot. (make sure to unpack and build in clean dirs..) [2009-04-29 14:27:02] thomas dot jarosch at intra2net dot com Is the latest snapshot compilable? I get this: /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:129: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'stream_cookie_functions' /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c: In function '_php_stream_cast': /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: error: 'stream_cookie_functions' undeclared (first use in this function) /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: error: (Each undeclared identifier is reported only once /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: error: for each function it appears in.) /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: warning: assignment makes pointer from integer without a cast /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:221: warning: passing argument 3 of '_php_stream_cast' makes pointer from integer without a cast [2009-04-27 19:14:40] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-06-05 15:41:29] thomas dot jarosch at intra2net dot com Description: Hello together, if you use a webmail applications like Horde's IMP and restart the server while an IMAP command is processing, PHP segfaults on request shutdown. Here's a backtrace of the crash: (gdb) bt #0 0x632f6564 in ?? () #1 0x01a6b575 in mail_close_full (stream=0x87b8ad8, options=0) at mail.c:1361 #2 0x01a494e3 in mail_close_it (rsrc=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/ext/imap/php_imap.c:229 #3 0x006dacc7 in list_entry_destructor (ptr=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:184 #4 0x006d8a3a in zend_hash_del_key_or_index (ht=0x7cb480, arKey=0x0, nKeyLength=0, h=81, flag=1) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:497 #5 0x006da915 in _zend_list_delete (id=81) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:58 #6 0x006cb9ed in _zval_dtor_func (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.c:60 #7 0x006be95e in _zval_dtor (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.h:35 #8 0x006bebac in _zval_ptr_dtor (zval_ptr=0xb79a9610) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:414 #9 0x006d8b33 in zend_hash_destroy (ht=0xb7a1a71c) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:526 #10 0x006eae64 in zend_object_std_dtor (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:45 #11 0x006eb287 in zend_objects_free_object_storage (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:122 #12 0x006eec3f in zend_objects_store_free_object_storage (objects=0x7cb528) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects_API.c:89 #13 0x006be7c7 in shutdown_executor () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:299 #14 0x006cd48d in zend_deactivate () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend.c:860 #15 0x0067d8d2 in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-5.2.6/main/main.c:1486 #16 0x00742f2f in php_apache_request_dtor (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:469 #17 0x007438ce in php_handler (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:641 #18 0x08065f19 in ap_run_handler () #19 0x08068f61 in ap_invoke_handler () #20 0x080639d8 in ap_process_request () #21 0x0805e6b8 in _start () I took a look at the structures in #1 mail_close_full (stream=0x87b8ad8, options=0), the memory was totally bogus and already reused. To me this looks like a use-after-free issue. While debugging I've found another crash in c-client's IMAP extension and I will submit a patch upstream. I was unable to find the source of this crash, but I suspect the connection already gets closed and then PHP tries to close it twice or something like that. Reproduce code: --- Move mails via IMAP to another folder and restart your IMAP
#45188 [Fbk-Opn]: Crash during request shutdown if mail server shuts down
ID: 45188 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: linux PHP Version: 5.2.6 New Comment: Is the latest snapshot compilable? I get this: /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:129: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'stream_cookie_functions' /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c: In function '_php_stream_cast': /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: error: 'stream_cookie_functions' undeclared (first use in this function) /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: error: (Each undeclared identifier is reported only once /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: error: for each function it appears in.) /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:181: warning: assignment makes pointer from integer without a cast /usr/src/redhat/BUILD/php5.2-200904291230/main/streams/cast.c:221: warning: passing argument 3 of '_php_stream_cast' makes pointer from integer without a cast Previous Comments: [2009-04-27 19:14:40] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-06-05 15:41:29] thomas dot jarosch at intra2net dot com Description: Hello together, if you use a webmail applications like Horde's IMP and restart the server while an IMAP command is processing, PHP segfaults on request shutdown. Here's a backtrace of the crash: (gdb) bt #0 0x632f6564 in ?? () #1 0x01a6b575 in mail_close_full (stream=0x87b8ad8, options=0) at mail.c:1361 #2 0x01a494e3 in mail_close_it (rsrc=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/ext/imap/php_imap.c:229 #3 0x006dacc7 in list_entry_destructor (ptr=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:184 #4 0x006d8a3a in zend_hash_del_key_or_index (ht=0x7cb480, arKey=0x0, nKeyLength=0, h=81, flag=1) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:497 #5 0x006da915 in _zend_list_delete (id=81) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:58 #6 0x006cb9ed in _zval_dtor_func (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.c:60 #7 0x006be95e in _zval_dtor (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.h:35 #8 0x006bebac in _zval_ptr_dtor (zval_ptr=0xb79a9610) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:414 #9 0x006d8b33 in zend_hash_destroy (ht=0xb7a1a71c) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:526 #10 0x006eae64 in zend_object_std_dtor (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:45 #11 0x006eb287 in zend_objects_free_object_storage (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:122 #12 0x006eec3f in zend_objects_store_free_object_storage (objects=0x7cb528) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects_API.c:89 #13 0x006be7c7 in shutdown_executor () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:299 #14 0x006cd48d in zend_deactivate () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend.c:860 #15 0x0067d8d2 in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-5.2.6/main/main.c:1486 #16 0x00742f2f in php_apache_request_dtor (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:469 #17 0x007438ce in php_handler (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:641 #18 0x08065f19 in ap_run_handler () #19 0x08068f61 in ap_invoke_handler () #20 0x080639d8 in ap_process_request () #21 0x0805e6b8 in _start () I took a look at the structures in #1 mail_close_full (stream=0x87b8ad8, options=0), the memory was totally bogus and already reused. To me this looks like a use-after-free issue. While debugging I've found another crash in c-client's IMAP extension and I will submit a patch upstream. I was unable to find the source of this crash, but I suspect the connection already gets closed and then PHP tries to close it twice or something like that. Reproduce code: --- Move mails via IMAP to another folder and restart your IMAP server. Expected result: Error message Connection to server died. Actual result: -- Segfault. -- Edit this bug report at http://bugs.php.net/?id=45188edit=1
#45213 [Ver]: imap_utf7_encode() computes wrong UTF-7 data
ID: 45213 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Verified Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-04-27) New Comment: As far as I know, iconv does not support IMAP modified UTF7 out of the box. Atleast my version 1.9.1 does not and I have a patch for exactly that. Though we can't rely on people having a patched iconv version. The c-client IMAP library has support for UTF8 - modified UTF7. Maybe that would be an option? Previous Comments: [2009-04-27 20:31:15] paj...@php.net Should we not simply rely on iconv in 5.2/5.3 and ICU in HEAD? [2009-04-27 19:07:23] j...@php.net Here is short and reliable test: # sapi/cli/php -r '$tst = mb_convert_encoding(täst, ISO-8859-1, UTF8); echo $tst, \n; echo imap_utf7_encode($tst), \n, mb_convert_encoding($tst, UTF7-IMAP, ISO-8859-1), \n;' [2008-06-09 13:17:53] thomas dot jarosch at intra2net dot com Description: Hello together, I tried to encode german umlauts using imap_utf7_encode(), but the computed string is not understood by the cyrus IMAP server. This is pretty much related to bug #15630, but now I had the help of a coworker who is pretty fast decoding base64 by hand :-) UTF-7 is defined to encode special characters as two byte UTF-16 stream. Normally the ISO-8859-1 string täst should be encoded into tAOQ-st, which corresponds to 0x00, 0xe4. The current code in PHP 5.2.6 encodes it to t5A-st, which is 0xe4 without the leading 0x00. Would be nice if that could be resolved since it's not compatible with most IMAP implementations. Bug #15630 is around since 2002. Cheers, Thomas Reproduce code: --- echo imap_utf7_encode(täst); Expected result: tAOQ-st Actual result: -- t5A-st -- Edit this bug report at http://bugs.php.net/?id=45213edit=1
#45948 [NEW]: dom extension segfaults because of another apache module
From: thomas dot jarosch at intra2net dot com Operating system: linux PHP version: 5.2.6 PHP Bug Type: DOM XML related Bug description: dom extension segfaults because of another apache module Description: Hello together, like last time in bug #29599, another apache module is using libxml2 and registering a global create/delete node callback. Right now PHP crashes on our site while using the dom extension because the callback still points to the other module. Guess libxml2 is to blame for providing -global- callbacks. Attached patch makes sure everything is clean and shiny when enter/leaving the request handled by PHP. The performance impact should be close to nothing. Hope it's useful to someone else. Link to patch: http://www.intra2net.com/de/download/opensource/php-5.2.6-fix- Thomas -- Edit bug report at http://bugs.php.net/?id=45948edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45948r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45948r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45948r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45948r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45948r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45948r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45948r=needscript Try newer version:http://bugs.php.net/fix.php?id=45948r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45948r=support Expected behavior:http://bugs.php.net/fix.php?id=45948r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45948r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45948r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45948r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45948r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45948r=dst IIS Stability:http://bugs.php.net/fix.php?id=45948r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45948r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45948r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45948r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45948r=mysqlcfg
#45948 [Com]: dom extension segfaults because of another apache module
ID: 45948 Comment by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: linux PHP Version: 5.2.6 New Comment: The link somehow gets cropped by the bugtracker, the filename is php-5.2.6-fix-libxmlpp-clash.patch Previous Comments: [2008-08-29 15:51:30] thomas dot jarosch at intra2net dot com Description: Hello together, like last time in bug #29599, another apache module is using libxml2 and registering a global create/delete node callback. Right now PHP crashes on our site while using the dom extension because the callback still points to the other module. Guess libxml2 is to blame for providing -global- callbacks. Attached patch makes sure everything is clean and shiny when enter/leaving the request handled by PHP. The performance impact should be close to nothing. Hope it's useful to someone else. Link to patch: http://www.intra2net.com/de/download/opensource/php-5.2.6-fix- Thomas -- Edit this bug report at http://bugs.php.net/?id=45948edit=1
#45178 [Csd]: garbage collector and cyclic references
ID: 45178
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
Status: Closed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-06-04 (snap)
Assigned To: dmitry
New Comment:
Thanks, Dmitry! Your fix works fine for both bugs.
Previous Comments:
[2008-07-24 13:38:22] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-07-16 13:20:31] thomas dot jarosch at intra2net dot com
Thanks for looking into this, Dmitry!
So there are actually two problems, one memory corruption reported
here and one memory leak report in #33595 or are they both memory
corruptions?
[2008-07-15 11:42:00] [EMAIL PROTECTED]
The simplest case for this memory corruption.
?php
class Foo {
function Foo() {
$this-error = array($this,$this);
}
}
$a = new Foo();
[2008-07-15 07:37:50] [EMAIL PROTECTED]
At first, you have a serious issue in your code. static variables
MUST NOT be asigned by reference, because they are already references.
As result the singleton pattern just doesn't work. BTW the bug is really
exists. The simplified test case follows(changing = new into = new
fixes memory corruption).
?php
class Horde_History {
function raiseError() {
return debug_backtrace();
}
function Horde_History() {
$this-error = $this-raiseError();
echo Memory usage: . memory_get_usage() . \n;
}
}
for ($i=0;$i10;$i++) {
$a = new Horde_History();
}
?
[2008-06-05 09:13:20] thomas dot jarosch at intra2net dot com
Actually, the reproduce code from #33595 also leaks memory.
The statement about Horde is not 100% correct as only some singleton
functions are affected. I mixed it up with another reference problem
I fixed a while ago. Nontheless memory is leaked :-)
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/45178
--
Edit this bug report at http://bugs.php.net/?id=45178edit=1
#45178 [Asn]: garbage collector and cyclic references
ID: 45178
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
Status: Assigned
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-06-04 (snap)
Assigned To: dmitry
New Comment:
Thanks for looking into this, Dmitry!
So there are actually two problems, one memory corruption reported
here and one memory leak report in #33595 or are they both memory
corruptions?
Previous Comments:
[2008-07-15 11:42:00] [EMAIL PROTECTED]
The simplest case for this memory corruption.
?php
class Foo {
function Foo() {
$this-error = array($this,$this);
}
}
$a = new Foo();
[2008-07-15 07:37:50] [EMAIL PROTECTED]
At first, you have a serious issue in your code. static variables
MUST NOT be asigned by reference, because they are already references.
As result the singleton pattern just doesn't work. BTW the bug is really
exists. The simplified test case follows(changing = new into = new
fixes memory corruption).
?php
class Horde_History {
function raiseError() {
return debug_backtrace();
}
function Horde_History() {
$this-error = $this-raiseError();
echo Memory usage: . memory_get_usage() . \n;
}
}
for ($i=0;$i10;$i++) {
$a = new Horde_History();
}
?
[2008-06-05 09:13:20] thomas dot jarosch at intra2net dot com
Actually, the reproduce code from #33595 also leaks memory.
The statement about Horde is not 100% correct as only some singleton
functions are affected. I mixed it up with another reference problem
I fixed a while ago. Nontheless memory is leaked :-)
[2008-06-04 16:57:45] thomas dot jarosch at intra2net dot com
Description:
Hello together,
I'm currently trying to find a heap corruption while using Horde and
noticed a rather odd behavior. The supplied code is the standard way
Horde does it singletons. We always used the syntax of $object =
new class to make it work with PHP4 and PHP5.
If I change that to $object = new class, everything works as
expected. I've found bug #32845 and noticed what we are doing seems
wrong, so Horde needs fixing.
The problem gets worse if the class object contains a variable of the
type PEAR_Error, which contains cyclic references. Not only does
the constructor get called every time, the object leaks memory like
hell, even with PHP 5.3. I've searched through the bugtracker and
thought the garbage collector now handles cyclic references,
but maybe this is a side-effect of something else going wrong.
Is the memory consumption by design?
Thanks in advance for any comment,
Thomas
Reproduce code:
---
?php
require_once PEAR.php;
class Horde_History
{
var $error;
function singleton()
{
static $history;
if (!isset($history)) {
$history = new Horde_History();
}
return $history;
}
function Horde_History()
{
$this-error = PEAR::raiseError(error);
echo Memory usage: . memory_get_usage() . \n;
}
}
for (;;) {
$a = Horde_History::singleton();
}
Expected result:
Constant memory usage.
Actual result:
--
Increasing memory usage.
--
Edit this bug report at http://bugs.php.net/?id=45178edit=1
#44945 [Bgs]: escapeshellarg removes UTF-8 multi-byte characters
ID: 44945
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
Status: Bogus
Bug Type: Strings related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
Thanks for looking into this, Jani.
So, why does it work via CLI and not via apache if the same LANG
environment variable is specified? I've even seen
an AddDefaultCharset UTF8 entry in the apache config.
Thomas
Previous Comments:
[2008-07-13 17:01:20] [EMAIL PROTECTED]
There's no automatic way. If you need to have it work with utf-8 of
course you have to set the locales properly too. Or just not use UTF-8..
[2008-05-08 12:59:36] thomas dot jarosch at intra2net dot com
Thanks, that seems to work.
I've inspected the environment on the server and it contains a
LANG=en_US.UTF-8 variable. Is there a way I can fix this/PHP
autodetects it without touching every code using escapeshellarg()?
[2008-05-08 11:28:25] [EMAIL PROTECTED]
Try with the code below (mandatory in the test):
if (false == setlocale(LC_CTYPE, UTF8, en_US.UTF-8)) {
die(skip setlocale() failed\n);
}
[2008-05-08 11:08:27] thomas dot jarosch at intra2net dot com
Description:
Hello together,
I'm seeing almost the same issue as #44564
after upgrading from PHP 5.2.5 to 5.2.6.
If I execute the provided test code via php CLI, everything works as
expected. Running the same code via mod_php inside Apache skips the
UTF-8 multi-byte characters.
I've looked at the ext/standard/exec.c code a bit and checked that
my config.log in both PHP build directories contains
#define HAVE_MBLEN 1 so the call to php_mblen() should work.
Any idea what that could be?
One thing I noticed is that php_mblen() is a wrapper macro for
mblen() or mbrlen() which features a slight difference in the return
code (see -2 rc for details).
Thanks,
Thomas
Reproduce code:
---
var_dump(escapeshellarg('ä'));
Expected result:
string(2) 'ä'
Actual result:
--
string(2) ''
--
Edit this bug report at http://bugs.php.net/?id=44945edit=1
#45213 [NEW]: imap_utf7_encode() computes wrong UTF-7 data
From: thomas dot jarosch at intra2net dot com Operating system: linux PHP version: 5.2.6 PHP Bug Type: IMAP related Bug description: imap_utf7_encode() computes wrong UTF-7 data Description: Hello together, I tried to encode german umlauts using imap_utf7_encode(), but the computed string is not understood by the cyrus IMAP server. This is pretty much related to bug #15630, but now I had the help of a coworker who is pretty fast decoding base64 by hand :-) UTF-7 is defined to encode special characters as two byte UTF-16 stream. Normally the ISO-8859-1 string täst should be encoded into tAOQ-st, which corresponds to 0x00, 0xe4. The current code in PHP 5.2.6 encodes it to t5A-st, which is 0xe4 without the leading 0x00. Would be nice if that could be resolved since it's not compatible with most IMAP implementations. Bug #15630 is around since 2002. Cheers, Thomas Reproduce code: --- echo imap_utf7_encode(täst); Expected result: tAOQ-st Actual result: -- t5A-st -- Edit bug report at http://bugs.php.net/?id=45213edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45213r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45213r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45213r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45213r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45213r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45213r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45213r=needscript Try newer version:http://bugs.php.net/fix.php?id=45213r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45213r=support Expected behavior:http://bugs.php.net/fix.php?id=45213r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45213r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45213r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45213r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45213r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45213r=dst IIS Stability:http://bugs.php.net/fix.php?id=45213r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45213r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45213r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45213r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45213r=mysqlcfg
#45178 [Opn]: garbage collector and cyclic references
ID: 45178
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-06-04 (snap)
New Comment:
Actually, the reproduce code from #33595 also leaks memory.
The statement about Horde is not 100% correct as only some singleton
functions are affected. I mixed it up with another reference problem
I fixed a while ago. Nontheless memory is leaked :-)
Previous Comments:
[2008-06-04 16:57:45] thomas dot jarosch at intra2net dot com
Description:
Hello together,
I'm currently trying to find a heap corruption while using Horde and
noticed a rather odd behavior. The supplied code is the standard way
Horde does it singletons. We always used the syntax of $object =
new class to make it work with PHP4 and PHP5.
If I change that to $object = new class, everything works as
expected. I've found bug #32845 and noticed what we are doing seems
wrong, so Horde needs fixing.
The problem gets worse if the class object contains a variable of the
type PEAR_Error, which contains cyclic references. Not only does
the constructor get called every time, the object leaks memory like
hell, even with PHP 5.3. I've searched through the bugtracker and
thought the garbage collector now handles cyclic references,
but maybe this is a side-effect of something else going wrong.
Is the memory consumption by design?
Thanks in advance for any comment,
Thomas
Reproduce code:
---
?php
require_once PEAR.php;
class Horde_History
{
var $error;
function singleton()
{
static $history;
if (!isset($history)) {
$history = new Horde_History();
}
return $history;
}
function Horde_History()
{
$this-error = PEAR::raiseError(error);
echo Memory usage: . memory_get_usage() . \n;
}
}
for (;;) {
$a = Horde_History::singleton();
}
Expected result:
Constant memory usage.
Actual result:
--
Increasing memory usage.
--
Edit this bug report at http://bugs.php.net/?id=45178edit=1
#45188 [NEW]: IMAP crash if server shuts down
From: thomas dot jarosch at intra2net dot com Operating system: linux PHP version: 5.2.6 PHP Bug Type: Reproducible crash Bug description: IMAP crash if server shuts down Description: Hello together, if you use a webmail applications like Horde's IMP and restart the server while an IMAP command is processing, PHP segfaults on request shutdown. Here's a backtrace of the crash: (gdb) bt #0 0x632f6564 in ?? () #1 0x01a6b575 in mail_close_full (stream=0x87b8ad8, options=0) at mail.c:1361 #2 0x01a494e3 in mail_close_it (rsrc=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/ext/imap/php_imap.c:229 #3 0x006dacc7 in list_entry_destructor (ptr=0xb7977840) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:184 #4 0x006d8a3a in zend_hash_del_key_or_index (ht=0x7cb480, arKey=0x0, nKeyLength=0, h=81, flag=1) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:497 #5 0x006da915 in _zend_list_delete (id=81) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_list.c:58 #6 0x006cb9ed in _zval_dtor_func (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.c:60 #7 0x006be95e in _zval_dtor (zvalue=0xb79d7a74) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_variables.h:35 #8 0x006bebac in _zval_ptr_dtor (zval_ptr=0xb79a9610) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:414 #9 0x006d8b33 in zend_hash_destroy (ht=0xb7a1a71c) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_hash.c:526 #10 0x006eae64 in zend_object_std_dtor (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:45 #11 0x006eb287 in zend_objects_free_object_storage (object=0xb7b9bf08) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects.c:122 #12 0x006eec3f in zend_objects_store_free_object_storage (objects=0x7cb528) at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_objects_API.c:89 #13 0x006be7c7 in shutdown_executor () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend_execute_API.c:299 #14 0x006cd48d in zend_deactivate () at /usr/src/redhat/BUILD/php-5.2.6/Zend/zend.c:860 #15 0x0067d8d2 in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-5.2.6/main/main.c:1486 #16 0x00742f2f in php_apache_request_dtor (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:469 #17 0x007438ce in php_handler (r=0x8776f70) at /usr/src/redhat/BUILD/php-5.2.6/sapi/apache2handler/sapi_apache2.c:641 #18 0x08065f19 in ap_run_handler () #19 0x08068f61 in ap_invoke_handler () #20 0x080639d8 in ap_process_request () #21 0x0805e6b8 in _start () I took a look at the structures in #1 mail_close_full (stream=0x87b8ad8, options=0), the memory was totally bogus and already reused. To me this looks like a use-after-free issue. While debugging I've found another crash in c-client's IMAP extension and I will submit a patch upstream. I was unable to find the source of this crash, but I suspect the connection already gets closed and then PHP tries to close it twice or something like that. Reproduce code: --- Move mails via IMAP to another folder and restart your IMAP server. Expected result: Error message Connection to server died. Actual result: -- Segfault. -- Edit bug report at http://bugs.php.net/?id=45188edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45188r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45188r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45188r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45188r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45188r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45188r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45188r=needscript Try newer version:http://bugs.php.net/fix.php?id=45188r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45188r=support Expected behavior:http://bugs.php.net/fix.php?id=45188r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45188r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45188r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45188r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45188r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45188r=dst IIS Stability:http://bugs.php.net/fix.php?id=45188r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45188r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45188r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45188r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45188r=mysqlcfg
#45178 [NEW]: garbage collector and cyclic references
From: thomas dot jarosch at intra2net dot com
Operating system: Linux
PHP version: 5.3CVS-2008-06-04 (snap)
PHP Bug Type: Reproducible crash
Bug description: garbage collector and cyclic references
Description:
Hello together,
I'm currently trying to find a heap corruption while using Horde and
noticed a rather odd behavior. The supplied code is the standard way
Horde does it singletons. We always used the syntax of $object =
new class to make it work with PHP4 and PHP5.
If I change that to $object = new class, everything works as
expected. I've found bug #32845 and noticed what we are doing seems
wrong, so Horde needs fixing.
The problem gets worse if the class object contains a variable of the
type PEAR_Error, which contains cyclic references. Not only does
the constructor get called every time, the object leaks memory like
hell, even with PHP 5.3. I've searched through the bugtracker and
thought the garbage collector now handles cyclic references,
but maybe this is a side-effect of something else going wrong.
Is the memory consumption by design?
Thanks in advance for any comment,
Thomas
Reproduce code:
---
?php
require_once PEAR.php;
class Horde_History
{
var $error;
function singleton()
{
static $history;
if (!isset($history)) {
$history = new Horde_History();
}
return $history;
}
function Horde_History()
{
$this-error = PEAR::raiseError(error);
echo Memory usage: . memory_get_usage() . \n;
}
}
for (;;) {
$a = Horde_History::singleton();
}
Expected result:
Constant memory usage.
Actual result:
--
Increasing memory usage.
--
Edit bug report at http://bugs.php.net/?id=45178edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45178r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45178r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45178r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45178r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45178r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45178r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45178r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45178r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45178r=support
Expected behavior:http://bugs.php.net/fix.php?id=45178r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45178r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45178r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45178r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45178r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45178r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45178r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45178r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45178r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45178r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45178r=mysqlcfg
#44945 [NEW]: escapeshellarg removes UTF-8 multi-byte characters
From: thomas dot jarosch at intra2net dot com
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: Strings related
Bug description: escapeshellarg removes UTF-8 multi-byte characters
Description:
Hello together,
I'm seeing almost the same issue as #44564
after upgrading from PHP 5.2.5 to 5.2.6.
If I execute the provided test code via php CLI, everything works as
expected. Running the same code via mod_php inside Apache skips the
UTF-8 multi-byte characters.
I've looked at the ext/standard/exec.c code a bit and checked that
my config.log in both PHP build directories contains
#define HAVE_MBLEN 1 so the call to php_mblen() should work.
Any idea what that could be?
One thing I noticed is that php_mblen() is a wrapper macro for
mblen() or mbrlen() which features a slight difference in the return
code (see -2 rc for details).
Thanks,
Thomas
Reproduce code:
---
var_dump(escapeshellarg('ä'));
Expected result:
string(2) 'ä'
Actual result:
--
string(2) ''
--
Edit bug report at http://bugs.php.net/?id=44945edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44945r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44945r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44945r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44945r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44945r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44945r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44945r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44945r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44945r=support
Expected behavior:http://bugs.php.net/fix.php?id=44945r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44945r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44945r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44945r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44945r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44945r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44945r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44945r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44945r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44945r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44945r=mysqlcfg
#44945 [Opn]: escapeshellarg removes UTF-8 multi-byte characters
ID: 44945
User updated by: thomas dot jarosch at intra2net dot com
Reported By: thomas dot jarosch at intra2net dot com
Status: Open
Bug Type: Strings related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
Thanks, that seems to work.
I've inspected the environment on the server and it contains a
LANG=en_US.UTF-8 variable. Is there a way I can fix this/PHP
autodetects it without touching every code using escapeshellarg()?
Previous Comments:
[2008-05-08 11:28:25] [EMAIL PROTECTED]
Try with the code below (mandatory in the test):
if (false == setlocale(LC_CTYPE, UTF8, en_US.UTF-8)) {
die(skip setlocale() failed\n);
}
[2008-05-08 11:08:27] thomas dot jarosch at intra2net dot com
Description:
Hello together,
I'm seeing almost the same issue as #44564
after upgrading from PHP 5.2.5 to 5.2.6.
If I execute the provided test code via php CLI, everything works as
expected. Running the same code via mod_php inside Apache skips the
UTF-8 multi-byte characters.
I've looked at the ext/standard/exec.c code a bit and checked that
my config.log in both PHP build directories contains
#define HAVE_MBLEN 1 so the call to php_mblen() should work.
Any idea what that could be?
One thing I noticed is that php_mblen() is a wrapper macro for
mblen() or mbrlen() which features a slight difference in the return
code (see -2 rc for details).
Thanks,
Thomas
Reproduce code:
---
var_dump(escapeshellarg('ä'));
Expected result:
string(2) 'ä'
Actual result:
--
string(2) ''
--
Edit this bug report at http://bugs.php.net/?id=44945edit=1
#44557 [NEW]: Fix crash in imap_setacl
From: thomas dot jarosch at intra2net dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: Reproducible crash Bug description: Fix crash in imap_setacl Description: Hello together, attached patch fixes a crash in imap_setacl if you pass an integer as username. Cheers, Thomas -- Edit bug report at http://bugs.php.net/?id=44557edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44557r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44557r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44557r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44557r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44557r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44557r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44557r=needscript Try newer version:http://bugs.php.net/fix.php?id=44557r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44557r=support Expected behavior:http://bugs.php.net/fix.php?id=44557r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44557r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44557r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44557r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44557r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44557r=dst IIS Stability:http://bugs.php.net/fix.php?id=44557r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44557r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44557r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44557r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44557r=mysqlcfg
#44557 [Opn]: Fix crash in imap_setacl
ID: 44557 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.2.5 New Comment: --- php-5.2.5/ext/imap/php_imap.c Fri Mar 28 13:28:28 2008 +++ php-5.2.5.new/ext/imap/php_imap.c Fri Mar 28 13:58:18 2008 PHP_FUNCTION(imap_setacl) @@ -1080,6 +1101,7 @@ ZEND_FETCH_RESOURCE(imap_le_struct, pils *, streamind, -1, imap, le_imap); convert_to_string_ex(mailbox); + convert_to_string_ex(id); convert_to_string_ex(rights); RETURN_BOOL(imap_setacl(imap_le_struct-imap_stream, Z_STRVAL_PP(mailbox), Z_STRVAL_PP(id), Z_STRVAL_PP(rights))); Previous Comments: [2008-03-28 13:20:48] thomas dot jarosch at intra2net dot com Description: Hello together, attached patch fixes a crash in imap_setacl if you pass an integer as username. Cheers, Thomas -- Edit this bug report at http://bugs.php.net/?id=44557edit=1
#29599 [Fbk-Opn]: domxml_error segfaults another apache module
ID: 29599 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com -Status: Feedback +Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: Another job well done :-) Works fine here! Though I'm curios where the xmlThrDefSetGenericErrorFunction is gone to. Won't this hurt threaded apaches or does the PHP_RINIT_FUNCTION take care of this? Previous Comments: [2004-08-13 12:24:04] [EMAIL PROTECTED] A fix is made, not committed yet. If you have the possibility, could you check http://trash.chregu.tv/php_domxml.diff.txt and see if it solves the problem? [2004-08-11 10:28:10] thomas dot jarosch at intra2net dot com Well, if it's not too much work, a backport would be nice. IMP v3 (webmail) doesn't support PHP5 yet, but I currently don't need domxml support and therefore disabled it. Thomas [2004-08-10 16:15:50] [EMAIL PROTECTED] The problem is fixed in PHP 5 Don't know, if we (meaning Rob) backport that to PHP 4... Depends on how much work it is, I assume. [2004-08-10 15:03:04] thomas dot jarosch at intra2net dot com Description: Hi, we're running PHP 4.3.8 as apache module, Apache runs without threads. The domxml extension registers an libxml2 generic error handler during its initialization. We have another apache module, which makes use of libxml2, this one doesn't register an error handler. When then second apache module encounters an XML error, apache segfaults in the domxml_error function. Here's a backtrace of the problem: #0 0x404d3448 in php_apache_sapi_send_headers () from ./etc/httpd/modules/libphp4.so #1 0x4049c84e in sapi_send_headers () from ./etc/httpd/modules/libphp4.so #2 0x4045c456 in php_header () from ./etc/httpd/modules/libphp4.so #3 0x404a7518 in php_ub_body_write () from ./etc/httpd/modules/libphp4.so #4 0x404a63b3 in php_body_write () from ./etc/httpd/modules/libphp4.so #5 0x404952eb in php_printf () from ./etc/httpd/modules/libphp4.so #6 0x40495a4d in php_error_cb () from ./etc/httpd/modules/libphp4.so #7 0x404c165f in zend_error () from ./etc/httpd/modules/libphp4.so #8 0x40495698 in php_verror () from ./etc/httpd/modules/libphp4.so #9 0x4049576f in php_error_docref0 () from ./etc/httpd/modules/libphp4.so #10 0x403c6951 in domxml_error () from ./etc/httpd/modules/libphp4.so #11 0x4083cb86 in xmlReportError (err=0x81dc978, ctxt=0x81dc7f8, str=0x81e03b0 Document is empty\n, channel=0x403c6910 domxml_error, data=0x0) at error.c:283 #12 0x4083ce9a in __xmlRaiseError (schannel=0, channel=0x4083d19c xmlParserError__internal_alias, data=0x81dc7f8, ctx=0x81dc7f8, nod=0x0, domain=1, code=4, level=XML_ERR_FATAL, file=0x81df640 , line=1, str1=0x0, str2=0x0, str3=0x0, int1=0, int2=0, msg=0x408d5111 Document is empty\n) at error.c:573 #13 0x4083fef4 in xmlFatalErr (ctxt=0x81dc7f8, error=1080649792, info=0x51 Address 0x51 out of bounds) at parser.c:360 #14 0x4084fa17 in xmlParseTryOrFinish (ctxt=0x81dc7f8, terminate=0) at parser.c:9098 #15 0x40850358 in xmlParseChunk__internal_alias (ctxt=0x81dc7f8, chunk=0x81dc9e4 í«îÛ\003, size=228, terminate=0) at parser.c:9763 #16 0x40cd108c in xmlpp::DomParser::parse_stream(std::istream) (this=0xbfffeab0, [EMAIL PROTECTED]) at basic_string.h:781 The problem is domxml's global error handler. Even if the second module would register an error handler, it would override PHP's error handler. IMHO the best approach would be to register the error handler only during operations calling libxml functions and deregister it afterwards. The performance overhead should be minimal and it's very clean. What do you think? Cheers, Thomas Actual result: -- See backtrace in description -- Edit this bug report at http://bugs.php.net/?id=29599edit=1
#29599 [Opn]: domxml_error segfaults another apache module
ID: 29599 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: Ok. Thanks for the patch again! Thomas Previous Comments: [2004-08-13 13:28:21] [EMAIL PROTECTED] according to rob, it's not needed anymore (he did the patch anyway..) [2004-08-13 13:23:57] thomas dot jarosch at intra2net dot com Another job well done :-) Works fine here! Though I'm curios where the xmlThrDefSetGenericErrorFunction is gone to. Won't this hurt threaded apaches or does the PHP_RINIT_FUNCTION take care of this? [2004-08-13 12:24:04] [EMAIL PROTECTED] A fix is made, not committed yet. If you have the possibility, could you check http://trash.chregu.tv/php_domxml.diff.txt and see if it solves the problem? [2004-08-11 10:28:10] thomas dot jarosch at intra2net dot com Well, if it's not too much work, a backport would be nice. IMP v3 (webmail) doesn't support PHP5 yet, but I currently don't need domxml support and therefore disabled it. Thomas [2004-08-10 16:15:50] [EMAIL PROTECTED] The problem is fixed in PHP 5 Don't know, if we (meaning Rob) backport that to PHP 4... Depends on how much work it is, I assume. 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/29599 -- Edit this bug report at http://bugs.php.net/?id=29599edit=1
#29599 [Opn]: domxml_error segfaults another apache module
ID: 29599 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: Well, if it's not too much work, a backport would be nice. IMP v3 (webmail) doesn't support PHP5 yet, but I currently don't need domxml support and therefore disabled it. Thomas Previous Comments: [2004-08-10 16:15:50] [EMAIL PROTECTED] The problem is fixed in PHP 5 Don't know, if we (meaning Rob) backport that to PHP 4... Depends on how much work it is, I assume. [2004-08-10 15:03:04] thomas dot jarosch at intra2net dot com Description: Hi, we're running PHP 4.3.8 as apache module, Apache runs without threads. The domxml extension registers an libxml2 generic error handler during its initialization. We have another apache module, which makes use of libxml2, this one doesn't register an error handler. When then second apache module encounters an XML error, apache segfaults in the domxml_error function. Here's a backtrace of the problem: #0 0x404d3448 in php_apache_sapi_send_headers () from ./etc/httpd/modules/libphp4.so #1 0x4049c84e in sapi_send_headers () from ./etc/httpd/modules/libphp4.so #2 0x4045c456 in php_header () from ./etc/httpd/modules/libphp4.so #3 0x404a7518 in php_ub_body_write () from ./etc/httpd/modules/libphp4.so #4 0x404a63b3 in php_body_write () from ./etc/httpd/modules/libphp4.so #5 0x404952eb in php_printf () from ./etc/httpd/modules/libphp4.so #6 0x40495a4d in php_error_cb () from ./etc/httpd/modules/libphp4.so #7 0x404c165f in zend_error () from ./etc/httpd/modules/libphp4.so #8 0x40495698 in php_verror () from ./etc/httpd/modules/libphp4.so #9 0x4049576f in php_error_docref0 () from ./etc/httpd/modules/libphp4.so #10 0x403c6951 in domxml_error () from ./etc/httpd/modules/libphp4.so #11 0x4083cb86 in xmlReportError (err=0x81dc978, ctxt=0x81dc7f8, str=0x81e03b0 Document is empty\n, channel=0x403c6910 domxml_error, data=0x0) at error.c:283 #12 0x4083ce9a in __xmlRaiseError (schannel=0, channel=0x4083d19c xmlParserError__internal_alias, data=0x81dc7f8, ctx=0x81dc7f8, nod=0x0, domain=1, code=4, level=XML_ERR_FATAL, file=0x81df640 , line=1, str1=0x0, str2=0x0, str3=0x0, int1=0, int2=0, msg=0x408d5111 Document is empty\n) at error.c:573 #13 0x4083fef4 in xmlFatalErr (ctxt=0x81dc7f8, error=1080649792, info=0x51 Address 0x51 out of bounds) at parser.c:360 #14 0x4084fa17 in xmlParseTryOrFinish (ctxt=0x81dc7f8, terminate=0) at parser.c:9098 #15 0x40850358 in xmlParseChunk__internal_alias (ctxt=0x81dc7f8, chunk=0x81dc9e4 í«îÛ\003, size=228, terminate=0) at parser.c:9763 #16 0x40cd108c in xmlpp::DomParser::parse_stream(std::istream) (this=0xbfffeab0, [EMAIL PROTECTED]) at basic_string.h:781 The problem is domxml's global error handler. Even if the second module would register an error handler, it would override PHP's error handler. IMHO the best approach would be to register the error handler only during operations calling libxml functions and deregister it afterwards. The performance overhead should be minimal and it's very clean. What do you think? Cheers, Thomas Actual result: -- See backtrace in description -- Edit this bug report at http://bugs.php.net/?id=29599edit=1
#29599 [NEW]: domxml_error segfaults another apache module
From: thomas dot jarosch at intra2net dot com Operating system: Linux PHP version: 4.3.8 PHP Bug Type: DOM XML related Bug description: domxml_error segfaults another apache module Description: Hi, we're running PHP 4.3.8 as apache module, Apache runs without threads. The domxml extension registers an libxml2 generic error handler during its initialization. We have another apache module, which makes use of libxml2, this one doesn't register an error handler. When then second apache module encounters an XML error, apache segfaults in the domxml_error function. Here's a backtrace of the problem: #0 0x404d3448 in php_apache_sapi_send_headers () from ./etc/httpd/modules/libphp4.so #1 0x4049c84e in sapi_send_headers () from ./etc/httpd/modules/libphp4.so #2 0x4045c456 in php_header () from ./etc/httpd/modules/libphp4.so #3 0x404a7518 in php_ub_body_write () from ./etc/httpd/modules/libphp4.so #4 0x404a63b3 in php_body_write () from ./etc/httpd/modules/libphp4.so #5 0x404952eb in php_printf () from ./etc/httpd/modules/libphp4.so #6 0x40495a4d in php_error_cb () from ./etc/httpd/modules/libphp4.so #7 0x404c165f in zend_error () from ./etc/httpd/modules/libphp4.so #8 0x40495698 in php_verror () from ./etc/httpd/modules/libphp4.so #9 0x4049576f in php_error_docref0 () from ./etc/httpd/modules/libphp4.so #10 0x403c6951 in domxml_error () from ./etc/httpd/modules/libphp4.so #11 0x4083cb86 in xmlReportError (err=0x81dc978, ctxt=0x81dc7f8, str=0x81e03b0 Document is empty\n, channel=0x403c6910 domxml_error, data=0x0) at error.c:283 #12 0x4083ce9a in __xmlRaiseError (schannel=0, channel=0x4083d19c xmlParserError__internal_alias, data=0x81dc7f8, ctx=0x81dc7f8, nod=0x0, domain=1, code=4, level=XML_ERR_FATAL, file=0x81df640 , line=1, str1=0x0, str2=0x0, str3=0x0, int1=0, int2=0, msg=0x408d5111 Document is empty\n) at error.c:573 #13 0x4083fef4 in xmlFatalErr (ctxt=0x81dc7f8, error=1080649792, info=0x51 Address 0x51 out of bounds) at parser.c:360 #14 0x4084fa17 in xmlParseTryOrFinish (ctxt=0x81dc7f8, terminate=0) at parser.c:9098 #15 0x40850358 in xmlParseChunk__internal_alias (ctxt=0x81dc7f8, chunk=0x81dc9e4 í«îÛ\003, size=228, terminate=0) at parser.c:9763 #16 0x40cd108c in xmlpp::DomParser::parse_stream(std::istream) (this=0xbfffeab0, [EMAIL PROTECTED]) at basic_string.h:781 The problem is domxml's global error handler. Even if the second module would register an error handler, it would override PHP's error handler. IMHO the best approach would be to register the error handler only during operations calling libxml functions and deregister it afterwards. The performance overhead should be minimal and it's very clean. What do you think? Cheers, Thomas Actual result: -- See backtrace in description -- Edit bug report at http://bugs.php.net/?id=29599edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29599r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29599r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29599r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29599r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29599r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29599r=needscript Try newer version: http://bugs.php.net/fix.php?id=29599r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29599r=support Expected behavior: http://bugs.php.net/fix.php?id=29599r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29599r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29599r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29599r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29599r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29599r=dst IIS Stability: http://bugs.php.net/fix.php?id=29599r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29599r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29599r=float
