#21641 [NEW]: stream_read() always passed count of 8192

2003-01-14 Thread web-php-bugs
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.18
PHP version:  4CVS-2003-01-14 (stable)
PHP Bug Type: Filesystem function related
Bug description:  stream_read() always passed count of 8192

The stream_read() method of a class registered with
stream_register_wrapper() is always passed 8192 as a count of bytes to
read no matter what the second argument is to an fread() on that stream.
This is reproduceable with the following class and test code:

fp = fopen($this->fn = $url['path'],$mode);
return ($this->fp ? true : false);
}

function stream_close()
{
fclose($this->fp);
}

function stream_read($count)
{
error_log("stream_read: $count ");
return fread($this->fp,$count);
}

function stream_write($data)
{
return fwrite($this->fp,$data);
}
function stream_eof()
{
return feof($this->fp);
}
function stream_tell()
{
return ftell($this->fp);
}
function stream_seek($offset,$whence)
{
return fseek($this->fp,$offset,$whence);
}
function stream_flush()
{
return fflush($this->fp);
}
}

stream_register_wrapper('filetest', 'Stream_File') or die("Can't register
filetest on Stream_File");

$fp = fopen("filetest://localhost/tmp/hello","w+");
fwrite($fp, "testing\n");
rewind($fp);
$data = fread($fp, 10);
echo "$data\n";
rewind($fp);
$data = fread($fp,32000);
echo "$data\n";
fclose($fp);
?>

Each time fread() is called on the stream, the error_log() call in
stream_read() prints:

stream_read: 8192

instead of "stream_read: 10" or "stream_read: 32000"

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




#21641 [Bgs->Opn]: stream_read() always passed count of 8192

2003-01-14 Thread web-php-bugs
 ID:   21641
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Linux 2.4.18
 PHP Version:  4CVS-2003-01-14 (stable)
 New Comment:

However, this causes problems for smaller values when the function that
stream_read() is calling doesn't like it when the byte count is larger
than its size. Consider this code (from the shared memory stream
wrapper I am working on)

function stream_read($count)
{
$data = shmop_read($this->shm,$this->pos,$count);
$this->pos += strlen($data);
return $data;
}

If the shared memory segment that $this->shm points to is less than
8192 bytes long, then shmop_read() complains that the count is out of
range. Here's some sample code if you want to try (thanks to Xavier
Noguer [[EMAIL PROTECTED]] who reported this to me):

shm_key = $url['host'];
if ((! intval($this->shm_key)) && (!
preg_match('/^0x[0-9a-f]+$/i',
   
$this->shm_key))) {
if ($options & STREAM_REPORT_ERRORS) {
trigger_error("Stream_SHM::stream_open: $this->shm_key
is not a valid shm key.",E_USER_ERROR);
}
return false;
}
if (intval($url['port'])) {
$this->size = intval($url['port']);
}
if (($mode != 'a') && ($mode != 'c') && 
($mode != 'w') && ($mode != 'n')) {
if ($options & STREAM_REPORT_ERRORS) {
trigger_error("Stream_SHM::stream_open: $mode is not a
valid mode (must be one of: a c n w)",E_USER_ERROR);
}
return false;
}
if (! ($this->shm =
shmop_open($this->shm_key,$mode,0600,$this->size))) {
if ($options & STREAM_REPORT_ERRORS) {
trigger_error('Stream_SHM::stream_open: shmop_open()
failed');
}
return false;
}
$this->size = shmop_size($this->shm);
return true;
}

function stream_close()
{
shmop_close($this->shm);
}

function stream_read($count)
{
$data = shmop_read($this->shm,$this->pos,$count);
$this->pos += strlen($data);
return $data;
}

function stream_write($data)
{
$count = shmop_write($this->shm,$data,$this->pos);
$this->pos += $count;
return $count;
}
function stream_eof()
{
return ($this->pos == ($this->size - 1));
}
function stream_tell()
{
return $this->pos;
}
function stream_seek($offset,$whence)
{
switch ($whence) {
case SEEK_SET:
if (($offset >= 0) && ($offset < $this->size)) {
$this->pos = $offset;
return true;
} else {
return false;
}
break;
case SEEK_CUR:
if (($offset >= 0) && (($this->pos + $offset) <
$this->size)) {
$this->pos += $offset;
return true;
} else {
return false;
}
break;
case SEEK_END:
if (($this->size + $offset) >= 0) {
$this->pos = $this->size + $offset;
return true;
} else {
return false;
}
break;
default:
return false;
}
}

function stream_flush()
{
return true;
}
}
  stream_register_wrapper('shm', 'Stream_SHM') 
 or die("Can't register shm on Stream_SHM");


  echo "\nUsing shm://0x:8192/\n";
  $mem = fopen("shm://0x:8192/","c");
  fwrite($mem, "hola\n");
  rewind($mem);
  $data = fread($mem, 4);
  echo "$data\n";
  fclose($mem);

  echo "\nUsing shm://0x:8191/\n";
  $mem = fopen("shm://0x:8191/","c");
  fwrite($mem, "hola\n");
  rewind($mem);
 $data = fread($mem, 4);
  echo "$data\n";
  fclose($mem);

  echo "\nUsing shmop_open() with size = 8191\n";
//shm://0x:8191/";
  $mem = shmop_open(0x, "c", 0600, 8191);
  $shm_bytes_written = shmop_write($mem, "hola", 0);
  $data = shmop_read($mem, 0, 4);
  echo "$data\n";
  shmop_close($mem);
?>

The first example, with the stream and an 8192 byte segment, works
fine. The last example, without the stream and with an 8191 byte
segment, works fine. The middle example, however, with the stream and
an 8191 byte segment fails, because the call to shmop_read() throws a
"count is out of range" error.


Previous Comments:


[2003-01-14 15:09:37] [EMAIL PROTECTED]

This is not a bug; PHP uses an internal read buffer 8192 bytes in
length in order to be more efficient.
You should note that fread() returns the correct number

#21641 [Bgs->Opn]: stream_read() always passed count of 8192

2003-01-14 Thread web-php-bugs
 ID:   21641
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Linux 2.4.18
 PHP Version:  4CVS-2003-01-14 (stable)
 New Comment:

I don't understand. In the shared memory example, how am I supposed to
be able to read just four bytes from the stream? When I pass 4 to
fread(), stream_open() gets 8192 $count. I can do the math just fine in
stream_open() to trim that to 8191 (or whatever's left between the
current position and the size of the segment), but that assumes that
the fread() call was to read the rest of the segment. It's not. It's
only for four bytes.


Previous Comments:


[2003-01-14 15:25:57] [EMAIL PROTECTED]

Not a bug.
Your stream should keep track of the maximum size available, and is
responsible for keeping within range of the functions it calls.
You already have a size and a position, you should be able to determine
the maximum readable size using that information.
If you don't want to see an error, you can use the @ operator.




[2003-01-14 15:20:44] [EMAIL PROTECTED]

However, this causes problems for smaller values when the function that
stream_read() is calling doesn't like it when the byte count is larger
than its size. Consider this code (from the shared memory stream
wrapper I am working on)

function stream_read($count)
{
$data = shmop_read($this->shm,$this->pos,$count);
$this->pos += strlen($data);
return $data;
}

If the shared memory segment that $this->shm points to is less than
8192 bytes long, then shmop_read() complains that the count is out of
range. Here's some sample code if you want to try (thanks to Xavier
Noguer [[EMAIL PROTECTED]] who reported this to me):

shm_key = $url['host'];
if ((! intval($this->shm_key)) && (!
preg_match('/^0x[0-9a-f]+$/i',
   
$this->shm_key))) {
if ($options & STREAM_REPORT_ERRORS) {
trigger_error("Stream_SHM::stream_open: $this->shm_key
is not a valid shm key.",E_USER_ERROR);
}
return false;
}
if (intval($url['port'])) {
$this->size = intval($url['port']);
}
if (($mode != 'a') && ($mode != 'c') && 
($mode != 'w') && ($mode != 'n')) {
if ($options & STREAM_REPORT_ERRORS) {
trigger_error("Stream_SHM::stream_open: $mode is not a
valid mode (must be one of: a c n w)",E_USER_ERROR);
}
return false;
}
if (! ($this->shm =
shmop_open($this->shm_key,$mode,0600,$this->size))) {
if ($options & STREAM_REPORT_ERRORS) {
trigger_error('Stream_SHM::stream_open: shmop_open()
failed');
}
return false;
}
$this->size = shmop_size($this->shm);
return true;
}

function stream_close()
{
shmop_close($this->shm);
}

function stream_read($count)
{
$data = shmop_read($this->shm,$this->pos,$count);
$this->pos += strlen($data);
return $data;
}

function stream_write($data)
{
$count = shmop_write($this->shm,$data,$this->pos);
$this->pos += $count;
return $count;
}
function stream_eof()
{
return ($this->pos == ($this->size - 1));
}
function stream_tell()
{
return $this->pos;
}
function stream_seek($offset,$whence)
{
switch ($whence) {
case SEEK_SET:
if (($offset >= 0) && ($offset < $this->size)) {
$this->pos = $offset;
return true;
} else {
return false;
}
break;
case SEEK_CUR:
if (($offset >= 0) && (($this->pos + $offset) <
$this->size)) {
$this->pos += $offset;
return true;
} else {
return false;
}
break;
case SEEK_END:
if (($this->size + $offset) >= 0) {
$this->pos = $this->size + $offset;
return true;
} else {
return false;
}
break;
default:
return false;
}
}

function stream_flush()
{
return true;
}
}
  stream_register_wrapper('shm', 'Stream_SHM') 
 or die("Can't register shm on Stream_SHM");


  echo "\nUsing shm://0x:8192/\n";
  $mem = fopen("shm://0x:8192/","c");
  fwrite($mem, "hola\n");
  rewind($mem);
  $data = fread($mem, 4);
  echo "$data\n";
  fclose($mem);

  echo "\nUsing shm://0x:81

Bug #16500: DL_ERROR() instead of dlerror() in ext/standard/dl.c 1.68 breaks build

2002-04-08 Thread web-php-bugs

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 7.1 / kernel 2.4.4
PHP version:  4.0CVS-2002-04-08
PHP Bug Type: Compile Failure
Bug description:  DL_ERROR() instead of dlerror() in ext/standard/dl.c 1.68 breaks 
build

dl.c version 1.68 line 48 defines GET_DL_ERROR() as DL_ERROR() instead of
(as in previous versions of dl.c) dlerror().

When building, that gives me the following error when gcc tries to link
together all of the various object files and libraries to make the php
binary:

ext/standard/dl.o: In function `php_dl':
/store/cvs/php/php4/ext/standard/dl.c:137: undefined reference to
`DL_ERROR'

If I change dl.c back to using dlerror() instead of DL_ERROR(), it builds
fine. Here is my configure command line:

./configure \
 --disable-short-tags \
 --enable-magic-quotes \
 --with-openssl \
 --with-zlib-dir=/usr/lib \
 --enable-calendar \
 --with-curl \
 --with-dom=/usr/local/lib \
 --with-gettext \
 --with-mcrypt \
 --with-mysql=/usr/local/mysql \
 --with-pgsql \
 --with-oci8=/store/oracle \
 --with-ncurses \
 --with-readline=/usr/local/lib \
 --with-mm=../mm-1.1.3 \
 --enable-sockets \
 --enable-sysvsem --enable-sysvshm \
 --with-iconv \
 --with-xmlrpc \
 --with-zip=/usr/local/lib \
 --enable-inline-optimization \
 --enable-dba \
 --with-gdbm \
 --with-ndbm \
 --with-db2 \
 --with-db3 \
 --with-shmop
-- 
Edit bug report at http://bugs.php.net/?id=16500&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16500&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16500&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16500&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16500&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16500&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16500&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16500&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16500&r=submittedtwice




Bug #16500 Updated: DL_ERROR() instead of dlerror() in ext/standard/dl.c 1.68 breaks build

2002-04-08 Thread web-php-bugs

 ID:   16500
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 7.1 / kernel 2.4.4
 PHP Version:  4.0CVS-2002-04-08
 New Comment:

I got it from CVS. I will update Zend and see what happens.


Previous Comments:


[2002-04-08 17:59:29] [EMAIL PROTECTED]

Did you get PHP from CVS or did you download a snapshot.
If the former, you just haven't updated Zend module.
If the latter, it might be some problem in the snapshot creation.




[2002-04-08 17:11:13] [EMAIL PROTECTED]

dl.c version 1.68 line 48 defines GET_DL_ERROR() as DL_ERROR() instead
of (as in previous versions of dl.c) dlerror().

When building, that gives me the following error when gcc tries to link
together all of the various object files and libraries to make the php
binary:

ext/standard/dl.o: In function `php_dl':
/store/cvs/php/php4/ext/standard/dl.c:137: undefined reference to
`DL_ERROR'

If I change dl.c back to using dlerror() instead of DL_ERROR(), it
builds fine. Here is my configure command line:

./configure \
 --disable-short-tags \
 --enable-magic-quotes \
 --with-openssl \
 --with-zlib-dir=/usr/lib \
 --enable-calendar \
 --with-curl \
 --with-dom=/usr/local/lib \
 --with-gettext \
 --with-mcrypt \
 --with-mysql=/usr/local/mysql \
 --with-pgsql \
 --with-oci8=/store/oracle \
 --with-ncurses \
 --with-readline=/usr/local/lib \
 --with-mm=../mm-1.1.3 \
 --enable-sockets \
 --enable-sysvsem --enable-sysvshm \
 --with-iconv \
 --with-xmlrpc \
 --with-zip=/usr/local/lib \
 --enable-inline-optimization \
 --enable-dba \
 --with-gdbm \
 --with-ndbm \
 --with-db2 \
 --with-db3 \
 --with-shmop




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




Bug #16500 Updated: DL_ERROR() instead of dlerror() in ext/standard/dl.c 1.68 breaks build

2002-04-08 Thread web-php-bugs

 ID:   16500
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 7.1 / kernel 2.4.4
 PHP Version:  4.0CVS-2002-04-08
 New Comment:

Updating Zend fixed it as recommended. Thanks for the help. I will be
sure to update both php and Zend (and TSRM, I suppose, just to be safe)
before rebuilding now.


Previous Comments:


[2002-04-08 18:10:58] [EMAIL PROTECTED]

I got it from CVS. I will update Zend and see what happens.



[2002-04-08 17:59:29] [EMAIL PROTECTED]

Did you get PHP from CVS or did you download a snapshot.
If the former, you just haven't updated Zend module.
If the latter, it might be some problem in the snapshot creation.




[2002-04-08 17:11:13] [EMAIL PROTECTED]

dl.c version 1.68 line 48 defines GET_DL_ERROR() as DL_ERROR() instead
of (as in previous versions of dl.c) dlerror().

When building, that gives me the following error when gcc tries to link
together all of the various object files and libraries to make the php
binary:

ext/standard/dl.o: In function `php_dl':
/store/cvs/php/php4/ext/standard/dl.c:137: undefined reference to
`DL_ERROR'

If I change dl.c back to using dlerror() instead of DL_ERROR(), it
builds fine. Here is my configure command line:

./configure \
 --disable-short-tags \
 --enable-magic-quotes \
 --with-openssl \
 --with-zlib-dir=/usr/lib \
 --enable-calendar \
 --with-curl \
 --with-dom=/usr/local/lib \
 --with-gettext \
 --with-mcrypt \
 --with-mysql=/usr/local/mysql \
 --with-pgsql \
 --with-oci8=/store/oracle \
 --with-ncurses \
 --with-readline=/usr/local/lib \
 --with-mm=../mm-1.1.3 \
 --enable-sockets \
 --enable-sysvsem --enable-sysvshm \
 --with-iconv \
 --with-xmlrpc \
 --with-zip=/usr/local/lib \
 --enable-inline-optimization \
 --enable-dba \
 --with-gdbm \
 --with-ndbm \
 --with-db2 \
 --with-db3 \
 --with-shmop




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




Bug #16211: ftruncate() won't truncate file

2002-03-21 Thread web-php-bugs

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 7.1 / kernel 2.4.4
PHP version:  4.0CVS-2002-03-21
PHP Bug Type: Filesystem function related
Bug description:  ftruncate() won't truncate file

Under the latest CVS, the following script fails (ftruncate() returns an
error and doesn't truncate the file) but under PHP 4.1.2, it works fine:



(The file "test" exists and has some text in it.)

I get the same results whether the mode passed to fopen() is "r", "r+",
"a", or "a+" (with "w" or "w+", the call to ftruncate() still fails, but
the file is truncated due to the nature of the "w" fopen mode).


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




#27010 [NEW]: segfault and node text not displayed when returned from children()

2004-01-22 Thread web-php-bugs at sklar dot com
From: web-php-bugs at sklar dot com
Operating system: Linux
PHP version:  5CVS-2004-01-22 (dev)
PHP Bug Type: XML related
Bug description:  segfault and node text not displayed when returned from children()

Description:

When iterating through the results of the SimpleXML children() method,
$element->name syntax returns the empty string instead of the text of the
"name" tag. var_dump($element), however reports the correct value for the
"name" property of $element.

Reproduce code:
---
$xml='
http://www.example.com/hot";>
 Coffee
 Tea
 Cola
 Juice
';
 
$sxe = simplexml_load_string($xml);


foreach ($sxe as $element_name => $element) {
print "$element_name is $element->name\n";
}

foreach ($sxe->children('http://www.example.com/hot') as $element_name =>
$element) {
print "$element_name is $element->name\n";
}

Expected result:

drink is Cola
drink is Juice
drink is Coffee
drink is Tea


Actual result:
--
drink is Cola
drink is Juice
drink is
drink is
Segmentation fault

Substituting var_dump($element) for the print statement produces:

object(simplexml_element)#5 (1) {
  ["name"]=>
  string(6) "Coffee"
}
object(simplexml_element)#4 (1) {
  ["name"]=>
  string(3) "Tea"
}

[New Thread 1076484640 (LWP 16144)]
drink is Cola
drink is Juice
drink is
drink is

On the segfault, GDB reports:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076484640 (LWP 16144)]
0x080eb813 in match_ns (sxe=0x402af9d4, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
124 if (!xmlStrcmp(node->ns->href, name)) {
(gdb) bt
#0  0x080eb813 in match_ns (sxe=0x402af9d4, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
#1  0x080eb2d6 in php_sxe_move_forward_iterator (sxe=0x402af9d4)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1394
#2  0x080eb3ea in php_sxe_iterator_move_forward (iter=0x402af94c)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1424
#3  0x082390c5 in zend_fe_fetch_handler (execute_data=0xbfffd5c0,
op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:3672
#4  0x0823221f in execute (op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:1264
#5  0x08210d11 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /opt/cvs/cvs.php.net/php-src/Zend/zend.c:1051
#6  0x081ce776 in php_execute_script (primary_file=0xb9c0)
at /opt/cvs/cvs.php.net/php-src/main/main.c:1642
#7  0x0824252c in main (argc=2, argv=0xba54)
at /opt/cvs/cvs.php.net/php-src/sapi/cli/php_cli.c:939
#8  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) p *node
$1 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x835c900 "drink",
  children = 0x835c968, last = 0x835c968, parent = 0x835c5d8,
  next = 0x835c9e8, prev = 0x835c8c8, doc = 0x835c4f0, ns = 0x0,
  content = 0x0, properties = 0x0, nsDef = 0x0}



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


#27010 [Opn]: segfault after returning nodes with children()

2004-01-22 Thread web-php-bugs at sklar dot com
 ID:   27010
 User updated by:  web-php-bugs at sklar dot com
-Summary:  segfault and node text not displayed when returned
   from children()
 Reported By:  web-php-bugs at sklar dot com
 Status:   Open
 Bug Type: XML related
 Operating System: Linux
 PHP Version:  5CVS-2004-01-22 (dev)
 New Comment:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076484640 (LWP 16185)]
0x080eb813 in match_ns (sxe=0x402afb74, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
124 if (!xmlStrcmp(node->ns->href, name)) {
(gdb) bt
#0  0x080eb813 in match_ns (sxe=0x402afb74, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
#1  0x080eb2d6 in php_sxe_move_forward_iterator (sxe=0x402afb74)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1394
#2  0x080eb3ea in php_sxe_iterator_move_forward (iter=0x402afaec)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1424
#3  0x082390c5 in zend_fe_fetch_handler (execute_data=0xbfffd0c0,
op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:3672
#4  0x0823221f in execute (op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:1264
#5  0x08210d11 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /opt/cvs/cvs.php.net/php-src/Zend/zend.c:1051
#6  0x081ce776 in php_execute_script (primary_file=0xb4c0)
at /opt/cvs/cvs.php.net/php-src/main/main.c:1642
#7  0x0824252c in main (argc=2, argv=0xb554)
at /opt/cvs/cvs.php.net/php-src/sapi/cli/php_cli.c:939
#8  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) p *node
$1 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x835c900
"drink",
  children = 0x835c968, last = 0x835c968, parent = 0x835c5d8,
  next = 0x835c9e8, prev = 0x835c8c8, doc = 0x835c4f0, ns = 0x0,
  content = 0x0, properties = 0x0, nsDef = 0x0}


Previous Comments:
--------

[2004-01-22 14:08:15] web-php-bugs at sklar dot com

Description:

When iterating through the results of the SimpleXML children() method,
$element->name syntax returns the empty string instead of the text of
the "name" tag. var_dump($element), however reports the correct value
for the "name" property of $element.

Reproduce code:
---
$xml='
http://www.example.com/hot";>
 Coffee
 Tea
 Cola
 Juice
';
 
$sxe = simplexml_load_string($xml);


foreach ($sxe as $element_name => $element) {
print "$element_name is $element->name\n";
}

foreach ($sxe->children('http://www.example.com/hot') as $element_name
=> $element) {
print "$element_name is $element->name\n";
}

Expected result:

drink is Cola
drink is Juice
drink is Coffee
drink is Tea


Actual result:
--
drink is Cola
drink is Juice
drink is
drink is
Segmentation fault

Substituting var_dump($element) for the print statement produces:

object(simplexml_element)#5 (1) {
  ["name"]=>
  string(6) "Coffee"
}
object(simplexml_element)#4 (1) {
  ["name"]=>
  string(3) "Tea"
}

[New Thread 1076484640 (LWP 16144)]
drink is Cola
drink is Juice
drink is
drink is

On the segfault, GDB reports:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076484640 (LWP 16144)]
0x080eb813 in match_ns (sxe=0x402af9d4, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
124 if (!xmlStrcmp(node->ns->href, name)) {
(gdb) bt
#0  0x080eb813 in match_ns (sxe=0x402af9d4, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
#1  0x080eb2d6 in php_sxe_move_forward_iterator (sxe=0x402af9d4)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1394
#2  0x080eb3ea in php_sxe_iterator_move_forward (iter=0x402af94c)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1424
#3  0x082390c5 in zend_fe_fetch_handler (execute_data=0xbfffd5c0,
op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:3672
#4  0x0823221f in execute (op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:1264
#5  0x08210d11 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /opt/cvs/cvs.php.net/php-src/Zend/zend.c:1051
#6  0x081ce776 in php_execute_script (primary_file=0xb9c0)
at /opt/cvs/cvs.php.net/php-src/main/main.c:1642
#7  0x0824252c in main (argc=2, argv=0xba54)
at /opt/cvs/cvs.php.net/php-src/sapi/cli/php_cli.c:939
#8  0x42015704 in __libc

#27010 [Opn]: segfault after returning nodes with children()

2004-01-22 Thread web-php-bugs at sklar dot com
 ID:   27010
 User updated by:  web-php-bugs at sklar dot com
 Reported By:  web-php-bugs at sklar dot com
 Status:   Open
 Bug Type: XML related
 Operating System: Linux
 PHP Version:  5CVS-2004-01-22 (dev)
 New Comment:

When I retrieve child elements like this:

foreach ($sxe->children('http://www.example.com/hot') as $element_name
=> $element) {
print "$element_name is
".$element->children('http://www.example.com/hot')."\n";
}

It works fine (duh). But I still get the segfault -- backtrace in my
previous comment.


Previous Comments:
------------

[2004-01-22 14:13:05] web-php-bugs at sklar dot com

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076484640 (LWP 16185)]
0x080eb813 in match_ns (sxe=0x402afb74, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
124 if (!xmlStrcmp(node->ns->href, name)) {
(gdb) bt
#0  0x080eb813 in match_ns (sxe=0x402afb74, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
#1  0x080eb2d6 in php_sxe_move_forward_iterator (sxe=0x402afb74)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1394
#2  0x080eb3ea in php_sxe_iterator_move_forward (iter=0x402afaec)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1424
#3  0x082390c5 in zend_fe_fetch_handler (execute_data=0xbfffd0c0,
op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:3672
#4  0x0823221f in execute (op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:1264
#5  0x08210d11 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /opt/cvs/cvs.php.net/php-src/Zend/zend.c:1051
#6  0x081ce776 in php_execute_script (primary_file=0xb4c0)
at /opt/cvs/cvs.php.net/php-src/main/main.c:1642
#7  0x0824252c in main (argc=2, argv=0xb554)
at /opt/cvs/cvs.php.net/php-src/sapi/cli/php_cli.c:939
#8  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) p *node
$1 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x835c900
"drink",
  children = 0x835c968, last = 0x835c968, parent = 0x835c5d8,
  next = 0x835c9e8, prev = 0x835c8c8, doc = 0x835c4f0, ns = 0x0,
  content = 0x0, properties = 0x0, nsDef = 0x0}

------------

[2004-01-22 14:08:15] web-php-bugs at sklar dot com

Description:

When iterating through the results of the SimpleXML children() method,
$element->name syntax returns the empty string instead of the text of
the "name" tag. var_dump($element), however reports the correct value
for the "name" property of $element.

Reproduce code:
---
$xml='
http://www.example.com/hot";>
 Coffee
 Tea
 Cola
 Juice
';
 
$sxe = simplexml_load_string($xml);


foreach ($sxe as $element_name => $element) {
print "$element_name is $element->name\n";
}

foreach ($sxe->children('http://www.example.com/hot') as $element_name
=> $element) {
print "$element_name is $element->name\n";
}

Expected result:

drink is Cola
drink is Juice
drink is Coffee
drink is Tea


Actual result:
--
drink is Cola
drink is Juice
drink is
drink is
Segmentation fault

Substituting var_dump($element) for the print statement produces:

object(simplexml_element)#5 (1) {
  ["name"]=>
  string(6) "Coffee"
}
object(simplexml_element)#4 (1) {
  ["name"]=>
  string(3) "Tea"
}

[New Thread 1076484640 (LWP 16144)]
drink is Cola
drink is Juice
drink is
drink is

On the segfault, GDB reports:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076484640 (LWP 16144)]
0x080eb813 in match_ns (sxe=0x402af9d4, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
124 if (!xmlStrcmp(node->ns->href, name)) {
(gdb) bt
#0  0x080eb813 in match_ns (sxe=0x402af9d4, node=0x835c910,
name=0x835c4b8 "http://www.example.com/hot";)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:124
#1  0x080eb2d6 in php_sxe_move_forward_iterator (sxe=0x402af9d4)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1394
#2  0x080eb3ea in php_sxe_iterator_move_forward (iter=0x402af94c)
at /opt/cvs/cvs.php.net/php-src/ext/simplexml/simplexml.c:1424
#3  0x082390c5 in zend_fe_fetch_handler (execute_data=0xbfffd5c0,
op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:3672
#4  0x0823221f in execute (op_array=0x402adb6c)
at /opt/cvs/cvs.php.net/php-src/Zend/zend_execute.c:1264
#5

#25428 [Com]: xmlrpc_server_call_method() causes segfault

2003-10-14 Thread web-php-bugs at sklar dot com
 ID:   25428
 Comment by:   web-php-bugs at sklar dot com
 Reported By:  mfladischer at gmx dot net
 Status:   Open
 Bug Type: XMLRPC-EPI related
 Operating System: RedHat 9
 PHP Version:  5CVS-2003-09-08 (dev)
 New Comment:

This diff against v1.35 of ext/xmlrpc/xmlrpc-epi.php.c fixes the
problem.

diff -r1.35 xmlrpc-epi-php.c
1033c1033,1037
<   set_output_options(&out, *output_opts);
---
>   if (argc == 3) {
> set_output_options(&out, NULL);
> } else {
> set_output_options(&out, *output_opts);
> }


Previous Comments:


[2003-09-08 03:38:40] mfladischer at gmx dot net

Description:

When i'm trying to run a XML-RPC server  (using the xml-rpc-extension)
with PHP5 i get a segfault.

Reproduce code:
---


Expected result:




 
  
   

 
  system.listMethods
 
 
  system.methodHelp
 
 
  system.methodSignature
 
 
  system.describeMethods
 
 
  system.multiCall
 
 
  system.getCapabilities
 

   
  
 



Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 19945)]
0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
1033set_output_options(&out, *output_opts);
(gdb) bt
#0  0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
#1  0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541
#2  0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687
#3  0x0829e834 in execute (op_array=0x408ee410) at
/linux/devel/php5/Zend/zend_execute.c:1267
#4  0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /linux/devel/php5/Zend/zend.c:1018
#5  0x0823f15c in php_execute_script (primary_file=0xb580) at
/linux/devel/php5/main/main.c:1625
#6  0x082acea7 in main (argc=2, argv=0xb614) at
/linux/devel/php5/sapi/cli/php_cli.c:910
#7  0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6






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


#32555 [Com]: strtotime("tomorrow") can return false

2005-04-05 Thread web-php-bugs at sklar dot com
 ID:   32555
 Comment by:   web-php-bugs at sklar dot com
 Reported By:  stickman at gmail dot com
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: FreeBSD 4.9
 PHP Version:  4.3.10
 Assigned To:  derick
 New Comment:

With PHP 4.3.9, 5.0.3, and a recent CVS checkout, the following script
(run in timezone US/Eastern):



produces:

Sat Apr  2 02:30:00 2005
Sun Apr  3 03:30:00 2005

Which seems like a reasonable way for strtotime() to behave when it's
called without a starting timestamp during the period that's less than
24 hours but more than 23 hours before a change to DST in a
DST-respecting locale. That is, report the local time that corresponds
to 86400 seconds after strtotime() is called.


Previous Comments:


[2005-04-05 22:31:29] [EMAIL PROTECTED]

I know about DST and stuff - i was just wondering what tomorrow should
do for 2.30am on the day before DST changes... that's not in the RFC
;-)



[2005-04-03 18:17:28] stickman at gmail dot com

Is there some kind of RFC for this? There's one for everything down to
slicing bread.

RFC 3339 - Date and Time on the Internet: Timestamps
The UTC time corresponding to 17:00 on 23rd March 2005 in New York may
depend on administrative decisions about daylight savings time.  This
specification steers well clear of such considerations.)

No wonder they do. Daylight Saving Time is scary. It starts at 1:59am
and hops ahead one hour and one minute to 3am. It's at different times
across the world (12:59am Western Europe, 1:59am US, 2:59am Eastern
Europe, different for every area of Russia). Arizona and Hawaii don't
have it, Indiana sort of has it, and it's on a different day every year
and different days across the world.

Good luck, sir.



[2005-04-03 15:58:28] [EMAIL PROTECTED]

Correct. Although I'm not totally sure what "tomorrow" should do here
then...



[2005-04-03 09:17:15] stickman at gmail dot com

Well duh. I didn't even notice but daylight savings is about that time.
Could it be that "tomorrow" didn't exist for an hour?



[2005-04-03 09:08:42] stickman at gmail dot com

Description:

Early morning on April 2nd, 2005 my website broke. I tracked it down to
strtotime("tomorrow") returning -1 instead of the expected "tomorrow"
timestamp. strtotime("today") worked fine.

Asked a friend to test strtotime("tomorrow") and it worked fine for him
on his server (set to a different time).

Tested strtotime("tomorrow") on another server, also on Pacific time,
and got false again.

Went to bed to deal with it in the morning and the problem had resolved
itself sometime between midnight and 7am.

Reproduce code:
---
#Run this code on April 2nd, sometime after midnight.
echo strtotime("tomorrow");

Expected result:

1112628800 (or thereabouts)

Actual result:
--
-1





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


#44295 [NEW]: DirectoryIterator::__construct() exception + set_error_handler broken

2008-02-29 Thread web-php-bugs at sklar dot com
From: web-php-bugs at sklar dot com
Operating system: OS X 10.4
PHP version:  5.2.5
PHP Bug Type: SPL related
Bug description:  DirectoryIterator::__construct() exception + 
set_error_handler broken

Description:

When set_error_handler() has been used to set a custom error handler, the
RuntimeException thrown by DirectoryIterator::__construct() is not handled
properly -- the user error handler runs and then code continues after the
constructor instead of the exception being thrown.

This is specific to DirectoryIterator, if you replace "$iter = new
DirectoryIterator($dir)" with just "throw new Exception('monkey');" in the
reproduce code below, the catch block executes OK.


Reproduce code:
---
http://bugs.php.net/?id=44295&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44295&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44295&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44295&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44295&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44295&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44295&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44295&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44295&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44295&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44295&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44295&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44295&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44295&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44295&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44295&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44295&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44295&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44295&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44295&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44295&r=mysqlcfg