Bug #14254 Updated: SQLERROR -439

[alan . frostick]

 ID:   14254
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Informix related
 Operating System: Solaris 8
 PHP Version:  4.0.6
 New Comment:

Referring to Bug #14254.

I can give some background clues which might help in resolving the
intermittent SQLCODE=-439 error faster.
I support the php scripts for the same server which Cedric supports.
We
have noted that our client has increased their volume of data and
traffic to the site dramatically since their intranet's inception over
a
year ago.

They're still using php3 (we're trying to convince them to pay us to
convert their scripts to php4, but presently can't guarantee this
would
resolve the problem since it's still being reported by others using
php4).

The effect seen is a refusal to connect to informix, caused by a peak
in
traffic. It's not something which is easily duplicated in a test
environment, and is a mercurial problem in that as soon as it occurs,
it
often dissappears again as suddenly. We've seen it occur regularly for
up to 40 minutes and then go away for several days.

Recently the complaint has been that some scripts simply return an
empty
page. On investigation this week I discovered these scripts were
building massive arrays while remaining connected to informix, and
apparently exceeding maximum script memory. It happens within 4-5
seconds so can't be the result of a timeout.

I suspect this is giving rise to accumulated garbage somewhere or
leaving locks in the database and has a serious effect on subsequent
attempts to connect to informix, which (sometimes) return SQLCODE=-439
error codes from ifx_connect().

We've tried using both ifx_connect and ifx_pconnect for the scripts,
but
this makes no apparent difference, just as increasing connection
limits
has failed to.

I've since optimised some of the offending scripts and this seems to
alleviate the problem in the short-term, but a huge overhaul of the
methods used is overdue but cannot be done so quickly, given the
complexity of the intranet.

We'd like a resolution of the problem as soon as possible, even with
scripts timing out or exceeding memory limits. I see you've recently
improved the memory threading, and wonder if this could finally crack
this long-standing problem?
Alan Frostick


Previous Comments:


[2001-11-28 07:26:16] [EMAIL PROTECTED]

a short script would not reproduce the conditions for recreating the
failure.

It happens when we have a lot of load and this with big scripts using
lots of memory and sometimes timing out.
If the timeout comes from the db connection being lost or vice versa is
hard to say

If we could isolate where in the php ifx interface callback functions
are used we would be a step further in solving this.




[2001-11-27 12:57:34] [EMAIL PROTECTED]

Can you please add a short PHP script with which you can
reproduce this ? Also, please try PHP 4.1.0 (to be released
very soon now) as it has some improvements to the threading
which might actually fix this problem.

(it was mentioned as one possibility in that mail you 
pointed to in the archives)

I don't have informix installed or any knowledge how to
set it up either so you need to help us in this.

And I don't have much time to spend on this either so please
be patient.

--Jani





[2001-11-27 12:36:25] [EMAIL PROTECTED]

Similarly to Bugs 13459 and 8267 we do get error 439.

on php 3.0.18 and 4.0.6

http://marc.theaimsgroup.com/?l=php-dev&m=97812975300057&w=2



we do have support from ifx.

they are prepared to help us

here qote from ifx support 



I have received this case and I have looked through the case history.
The

situation appears to be as follows.



Your network traffic has increased and that in turn brought about
more

timeout situations where an ESQL/C callback was used by your
application (or

by PHP). The -439 error indicates that unauthorized calls are included
in

that callback function.



There are two ways to avoid getting the errors.



1. Tweak the system to increase performance to the point where the

timeouts do not occur.

2. Fix the callback function code.



Since you have indicated that you will not attempt number 1 we are left
with

number 2. Number 2 is the responsibility of the person that wrote the

callback function, be that you or PHP. 



The only way that Informix can fix the problem is if the -439 is being
given

in error. At this time there is no indication that the -439 error is
not

correct but it is still a possibility. Unfortunately we cannot know
whether

or n

Bug #17236 Updated: trans-sid only replace links in first 4138chars

[alan]

 ID:   17236
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: FreeBSD
 PHP Version:  4.2.1
 New Comment:

fter some further investigation:

This can be reproduced in php4.1.2 by changing the php.ini setting
output_buffering = 4000
IN 4.1.2
if it is 'off' = code works perfectly
if it is 4000 (or any number) = code has same problem
IN 4.2.1
if it is 'off or 4000' code has problems.

looking at 4.3 - all this stuff has been completely re-written :)


Previous Comments:


[2002-05-15 02:25:36] [EMAIL PROTECTED]

OK, This is a strange one. the whole application works perfectly on
4.0*/4.1*, but we started testing with 4.2.1
 
I'm filing it as a trans-sid bug (as thats whats noticable the most)-
but it could be 
 - output buffer?!?
 - class variable issues..
 - other weird stuff
 


Part of the html/php page  



is_Requestor() ) { ?> 



---Output from the html page




 

___^___ notice the misformed html in the output.


the output is somehow getting messed up...

CONFIGURE LINE
 './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-system-regex' '--disable-debug' '--enable-track-vars'
'--without-gd' '--with-mysql' '--enable-trans-sid'
 
 
QUICK OVERVIEW OF FEATURE USED:
trans-sess-id sessions are being used  and it does manage to replace
all href with the 'sid' before (roughly) the 4138th character, 
after that, even if the break is in a valid place 'htmlwize', it will
not replace any hrefs after that postition.

the file/code above is included from within a class instance method 
eg. something like this.
class default_page {
var $template = "home.html";
function output() {
$template->compile($this->template);

global $session,$config;
$auth = &$session->auth;
include($template->ouput_file);

}
}




regards
alan




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

Bug #17236: trans-sid only replace links in first 4138chars

[alan]

From: [EMAIL PROTECTED]
Operating system: FreeBSD
PHP version:  4.2.1
PHP Bug Type: Session related
Bug description:  trans-sid only replace links in first 4138chars

OK, This is a strange one. the whole application works perfectly on
4.0*/4.1*, but we started testing with 4.2.1
 
I'm filing it as a trans-sid bug (as thats whats noticable the most)- but
it could be 
 - output buffer?!?
 - class variable issues..
 - other weird stuff
 


Part of the html/php page  



is_Requestor() ) { ?> 



---Output from the html page




 

___^___ notice the misformed html in the output.


the output is somehow getting messed up...

CONFIGURE LINE
 './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-system-regex' '--disable-debug' '--enable-track-vars'
'--without-gd' '--with-mysql' '--enable-trans-sid'
 
 
QUICK OVERVIEW OF FEATURE USED:
trans-sess-id sessions are being used  and it does manage to replace all
href with the 'sid' before (roughly) the 4138th character, 
after that, even if the break is in a valid place 'htmlwize', it will not
replace any hrefs after that postition.

the file/code above is included from within a class instance method 
eg. something like this.
class default_page {
var $template = "home.html";
function output() {
$template->compile($this->template);

global $session,$config;
$auth = &$session->auth;
include($template->ouput_file);

}
}




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

Bug #17000: casting GLOBALS to object causes segfault.

[alan]

From: [EMAIL PROTECTED]
Operating system: linux (debian)
PHP version:  4.2.0
PHP Bug Type: Reproducible crash
Bug description:  casting GLOBALS to object causes segfault.

simple script


result = segfault.

Workaround (dont do it!)

Backtrace

Program received signal SIGSEGV, Segmentation fault.
0x4014dd4d in free () from /lib/libc.so.6
(gdb) bt
#0  0x4014dd4d in free () from /lib/libc.so.6
#1  0x4014dc13 in free () from /lib/libc.so.6
#2  0x80c51b0 in shutdown_memory_manager (silent=0, clean_cache=0)
at zend_alloc.c:484
#3  0x805d3ee in php_request_shutdown (dummy=0x0) at main.c:794
#4  0x805c190 in main (argc=2, argv=0xbc54) at cgi_main.c:834
#5  0x400f86cf in __libc_start_main () from /lib/libc.so.
-- 
Edit bug report at http://bugs.php.net/?id=17000&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=17000&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17000&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=17000&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=17000&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17000&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=17000&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17000&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17000&r=submittedtwice

Bug #16939 Updated: tokenizer: emalloc causes segfault

[alan]

 ID:   16939
 Updated by:   [EMAIL PROTECTED]
-Summary:  emalloc causes segfault (example uses tokenizer)
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: linux
 PHP Version:  4.2.0
 New Comment:

OK, Got a nice simple test case - I'm pretty certain its the tokenizer
code, Andrei :)

-- theres not category for tokenizer yet! :)

test script as follows (modify the directory to point at pear)..

data =& token_get_all($f);
   }
   function recurse($dir) {
   $dh = opendir($dir);
   while (($f = readdir($dh)) !== FALSE) {
  if ($f{0} == ".") continue;
   $fn = "{$dir}/{$f}";
   if (is_dir($fn)) {
$this->recurse($fn);
continue;
   }
   // assume its a file
   $this->testing($fn);
   }
   }
}
$t = new test;
// change this to your pear directory.
$t->recurse('/usr/lib/php');
?>


Previous Comments:


[2002-05-01 03:09:54] [EMAIL PROTECTED]

Workaround:

Original code did this
$this->tokens = token_get_all($filename)

by not reassigning the same variable on each file, but rather really
storing the token array in a huge array it works around this issue...
(albiet with a huge memory overhead)
  
$this->all_tokens[$filename] = token_get_all($contents);
$this->tokens =& $this->all_tokens[$filename];



[2002-05-01 02:40:23] [EMAIL PROTECTED]

A short script to reproduce this
(sorry it not to easy to reproduce without the exact code, I did at one
point get to the situation where adding a extra space in the white
space area solved this!), but I suspect it is that the machine is
running low on memory or something

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/uml_generator.class?rev=1.2&content-type=text/vnd.viewcvs-markup


http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/uml_dia.xml.php?rev=1.1&content-type=text/vnd.viewcvs-markup


-- just use it do do a large number of files. eg.
php uml_generator.class /usr/local/php/pear/

Possible reasons that I could think of:
-the tokenizer extension (which may be leaking memory)
-somewhere not exiting if no memory can be allocated and then emalloc /
malloc being called again.

Configuration on this machine (4.2.0RC2), also reproduced with 4.2
release version
'./configure' '--prefix=/usr' '--without-mysql'
'--with-config-file-path=/etc/php4/cgi/' '--enable-dba' '--with-db2'
and tokenizer as a dl'd module

Backtrace

Program received signal SIGSEGV, Segmentation fault.
0x4014db2b in malloc () from /lib/libc.so.6
(gdb) bt
#0  0x4014db2b in malloc () from /lib/libc.so.6
#1  0x4014d1e4 in malloc () from /lib/libc.so.6
#2  0x80c4c5c in _emalloc (size=35) at zend_alloc.c:165
#3  0x80d4b1a in zend_hash_index_update_or_next_insert (ht=0x817ae9c,
h=207, 
pData=0xbfffda28, nDataSize=4, pDest=0x0, flag=4) at
zend_hash.c:404
#4  0x80d303a in add_next_index_stringl (arg=0x8326d64, str=0x8268c08
")", length=1, 
duplicate=1) at zend_API.c:847
#5  0x401ffc61 in tokenize () from /usr/lib/php4/cgi/tokenizer.so
#6  0x402005ac in zif_token_get_all () from
/usr/lib/php4/cgi/tokenizer.so
#7  0x80eb4b0 in execute (op_array=0x816631c) at ./zend_execute.c:1598
#8  0x80eb679 in execute (op_array=0x8166a84) at ./zend_execute.c:1638
#9  0x80eb679 in execute (op_array=0x816004c) at ./zend_execute.c:1638
#10 0x80d19e8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:810
#11 0x805e1dd in php_execute_script (primary_file=0xbb98) at
main.c:1381
#12 0x805c0ac in main (argc=3, argv=0xbc14) at cgi_main.c:785
#13 0x400f86cf in __libc_start_main () from /lib/libc.so.6






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

Bug #16939 Updated: emalloc causes segfault (example uses tokenizer)

[alan]

 ID:   16939
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: linux
 PHP Version:  4.2.0
 New Comment:

Workaround:

Original code did this
$this->tokens = token_get_all($filename)

by not reassigning the same variable on each file, but rather really
storing the token array in a huge array it works around this issue...
(albiet with a huge memory overhead)
  
$this->all_tokens[$filename] = token_get_all($contents);
$this->tokens =& $this->all_tokens[$filename];


Previous Comments:


[2002-05-01 02:40:23] [EMAIL PROTECTED]

A short script to reproduce this
(sorry it not to easy to reproduce without the exact code, I did at one
point get to the situation where adding a extra space in the white
space area solved this!), but I suspect it is that the machine is
running low on memory or something

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/uml_generator.class?rev=1.2&content-type=text/vnd.viewcvs-markup


http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/uml_dia.xml.php?rev=1.1&content-type=text/vnd.viewcvs-markup


-- just use it do do a large number of files. eg.
php uml_generator.class /usr/local/php/pear/

Possible reasons that I could think of:
-the tokenizer extension (which may be leaking memory)
-somewhere not exiting if no memory can be allocated and then emalloc /
malloc being called again.

Configuration on this machine (4.2.0RC2), also reproduced with 4.2
release version
'./configure' '--prefix=/usr' '--without-mysql'
'--with-config-file-path=/etc/php4/cgi/' '--enable-dba' '--with-db2'
and tokenizer as a dl'd module

Backtrace

Program received signal SIGSEGV, Segmentation fault.
0x4014db2b in malloc () from /lib/libc.so.6
(gdb) bt
#0  0x4014db2b in malloc () from /lib/libc.so.6
#1  0x4014d1e4 in malloc () from /lib/libc.so.6
#2  0x80c4c5c in _emalloc (size=35) at zend_alloc.c:165
#3  0x80d4b1a in zend_hash_index_update_or_next_insert (ht=0x817ae9c,
h=207, 
pData=0xbfffda28, nDataSize=4, pDest=0x0, flag=4) at
zend_hash.c:404
#4  0x80d303a in add_next_index_stringl (arg=0x8326d64, str=0x8268c08
")", length=1, 
duplicate=1) at zend_API.c:847
#5  0x401ffc61 in tokenize () from /usr/lib/php4/cgi/tokenizer.so
#6  0x402005ac in zif_token_get_all () from
/usr/lib/php4/cgi/tokenizer.so
#7  0x80eb4b0 in execute (op_array=0x816631c) at ./zend_execute.c:1598
#8  0x80eb679 in execute (op_array=0x8166a84) at ./zend_execute.c:1638
#9  0x80eb679 in execute (op_array=0x816004c) at ./zend_execute.c:1638
#10 0x80d19e8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:810
#11 0x805e1dd in php_execute_script (primary_file=0xbb98) at
main.c:1381
#12 0x805c0ac in main (argc=3, argv=0xbc14) at cgi_main.c:785
#13 0x400f86cf in __libc_start_main () from /lib/libc.so.6






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

Bug #16939: emalloc causes segfault (example uses tokenizer)

[alan]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.2.0
PHP Bug Type: Reproducible crash
Bug description:  emalloc causes segfault (example uses tokenizer)

A short script to reproduce this
(sorry it not to easy to reproduce without the exact code, I did at one
point get to the situation where adding a extra space in the white space
area solved this!), but I suspect it is that the machine is running low on
memory or something

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/uml_generator.class?rev=1.2&content-type=text/vnd.viewcvs-markup


http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/uml_dia.xml.php?rev=1.1&content-type=text/vnd.viewcvs-markup


-- just use it do do a large number of files. eg.
php uml_generator.class /usr/local/php/pear/

Possible reasons that I could think of:
-the tokenizer extension (which may be leaking memory)
-somewhere not exiting if no memory can be allocated and then emalloc /
malloc being called again.

Configuration on this machine (4.2.0RC2), also reproduced with 4.2 release
version
'./configure' '--prefix=/usr' '--without-mysql'
'--with-config-file-path=/etc/php4/cgi/' '--enable-dba' '--with-db2'
and tokenizer as a dl'd module

Backtrace

Program received signal SIGSEGV, Segmentation fault.
0x4014db2b in malloc () from /lib/libc.so.6
(gdb) bt
#0  0x4014db2b in malloc () from /lib/libc.so.6
#1  0x4014d1e4 in malloc () from /lib/libc.so.6
#2  0x80c4c5c in _emalloc (size=35) at zend_alloc.c:165
#3  0x80d4b1a in zend_hash_index_update_or_next_insert (ht=0x817ae9c,
h=207, 
pData=0xbfffda28, nDataSize=4, pDest=0x0, flag=4) at zend_hash.c:404
#4  0x80d303a in add_next_index_stringl (arg=0x8326d64, str=0x8268c08 ")",
length=1, 
duplicate=1) at zend_API.c:847
#5  0x401ffc61 in tokenize () from /usr/lib/php4/cgi/tokenizer.so
#6  0x402005ac in zif_token_get_all () from
/usr/lib/php4/cgi/tokenizer.so
#7  0x80eb4b0 in execute (op_array=0x816631c) at ./zend_execute.c:1598
#8  0x80eb679 in execute (op_array=0x8166a84) at ./zend_execute.c:1638
#9  0x80eb679 in execute (op_array=0x816004c) at ./zend_execute.c:1638
#10 0x80d19e8 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:810
#11 0x805e1dd in php_execute_script (primary_file=0xbb98) at
main.c:1381
#12 0x805c0ac in main (argc=3, argv=0xbc14) at cgi_main.c:785
#13 0x400f86cf in __libc_start_main () from /lib/libc.so.6


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

Bug #16482: change in db2 breaks 4.2.0RC2

[alan]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0CVS-2002-04-07
PHP Bug Type: DBM/DBA related
Bug description:  change in db2 breaks 4.2.0RC2

this change in dba_db2.c changed the behaviour of db_open so that it fails
on success

if(!(ret = db_open(info->path, type, gmode, filemode, NULL, NULL, &dbp)))

became 

if(db_open(info->path, type, gmode, filemode, NULL, NULL, &dbp)) {

seems to work ok if it is changed to !db_open(

http://cvs.php.net/diff.php/php4/ext/dba/dba_db2.c?r1=1.18&r2=1.19&ty=u&Horde=4af7943402097520ae8f0622dab6804b
-- 
Edit bug report at http://bugs.php.net/?id=16482&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16482&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16482&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16482&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16482&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16482&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16482&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16482&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16482&r=submittedtwice

Bug #16232: remalloc FAIL on CURLOPT_HEADERFUNCTION callback

[alan]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0CVS-2002-03-23
PHP Bug Type: cURL related
Bug description:  remalloc FAIL on CURLOPT_HEADERFUNCTION callback

Fixes:
callback to curl_setopt(CURLOPT_HEADERFUNCTION..) always causes this.
FATAL:  erealloc():  Unable to allocate 1075529781 bytes

Fix:
Basically a copy of the curl_write to curl_write_header

Affects: 
all versions (that I know of - including 4.2.0rc1 & 4.2.0-dev)

test code at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpmole-ide/phpmole/tools/web_get.php?rev=1.2&content-type=text/vnd.viewcvs-markup


usage:
php web_get.php http://www.php.net
 




Index: curl.c
===
RCS file: /repository/php4/ext/curl/curl.c,v
retrieving revision 1.103
diff -u -r1.103 curl.c
--- curl.c  24 Dec 2001 13:58:03 -  1.103
+++ curl.c  23 Mar 2002 14:57:05 -
@@ -319,7 +319,7 @@
 
ZVAL_RESOURCE(argv[0], ch->id);
zend_list_addref(ch->id);
-   ZVAL_STRINGL(argv[1], data, (int) length, 1);
+   ZVAL_STRINGL(argv[1], data, length, 1);
 
error = call_user_function(EG(function_table),
   NULL,
@@ -373,7 +373,7 @@
zend_list_addref(ch->id);
ZVAL_RESOURCE(argv[1], t->fd);
zend_list_addref(t->fd);
-   ZVAL_LONG(argv[2], size * nmemb);
+   ZVAL_LONG(argv[2], (int) size * nmemb);
 
error = call_user_function(EG(function_table),
   NULL,
@@ -406,8 +406,7 @@
 {
php_curl   *ch  = (php_curl *) ctx;
php_curl_write *t   = ch->handlers->write_header;
-   int error;
-   int length;
+   size_t  length = size * nmemb;
TSRMLS_FETCH();

switch (t->method) {
@@ -415,33 +414,30 @@
/* Handle special case write when we're returning the entire transfer
 */
if (ch->handlers->write->method == PHP_CURL_RETURN)
-   smart_str_appendl(&ch->handlers->write->buf, data, size * 
nmemb);
+   smart_str_appendl(&ch->handlers->write->buf, data, (int) 
+length);
else
PUTS(data);
-
-   length = size * nmemb;
-
break;
case PHP_CURL_FILE:
-   length = fwrite(data, size, nmemb, t->fp);
-   break;
+   return fwrite(data, size, nmemb, t->fp);
case PHP_CURL_USER: {
zval *argv[2];
zval *retval;
+   int   error;
TSRMLS_FETCH();
-   
+
MAKE_STD_ZVAL(argv[0]);
MAKE_STD_ZVAL(argv[1]);
MAKE_STD_ZVAL(retval);
 
ZVAL_RESOURCE(argv[0], ch->id);
zend_list_addref(ch->id);
-   ZVAL_STRINGL(argv[0], data, size * nmemb, 1);
+   ZVAL_STRINGL(argv[1], data, length, 1);
 
-   error = call_user_function(EG(function_table), 
-  NULL,
+   error = call_user_function(EG(function_table),
+  NULL,
   t->func,
-  retval, 2, argv TSRMLS_CC);
+  retval, 2, argv TSRMLS_CC);
if (error == FAILURE) {
php_error(E_WARNING, "Couldn't call the 
CURLOPT_HEADERFUNCTION");
length = -1;
@@ -449,17 +445,14 @@
else {
length = Z_LVAL_P(retval);
}
-
zval_ptr_dtor(&argv[0]);
zval_ptr_dtor(&argv[1]);
zval_ptr_dtor(&retval);
break;
}
case PHP_CURL_IGNORE:
-   length = size * nmemb;
-   break;
-   }
-   
+   return length;
+   }
return length;
 }
 /* }}} */

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