Re: [PHP-DEV] Bug #14196 Updated: segmentation fault committing nothing

[Markus Fischer]

On Fri, Nov 23, 2001 at 02:42:42PM -, [EMAIL PROTECTED] wrote : 
> ID: 14196
> User updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PROTECTED]
> Old Status: Feedback
> Status: Open
> Bug Type: PostgreSQL related
> Operating System: Redhat 6.2
> PHP Version: 4.0.6
> New Comment:
> 
> To be clear, this is not a perfectly legal use of commit or
> rollback because a begin work statement should precede them. If
> begin work is used everything is fine.

Yeah, sure. But still want to know if this happens with
latest RC :)

If it still segfaults, can you send the smalles script which
accesses pg database which reproduces this?

- Markus

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

Re: [PHP-DEV] Out of date modules etc

[Jon Parise]

On Fri, Nov 23, 2001 at 02:32:49PM -, James Moore wrote:

> CCVS has now been dropped by redhat (it will be replaced by
> MCVE), the module doesnt really seem to be supported either.
> With sablotron going the same way (for different reasons
> though) perhaps we should create a unsupported or and old
> directory in the pear c extension repository for these modules
> to reside and move them out of php4/ext.

Sounds like a plan to me.  This will help populate PEAR with some
C code, too, which will encourage the development of that part of
the PEAR infrastructure.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Information Technology (2001)
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

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

Re: [PHP-DEV] CGI quick cleanup

[Andi Gutmans]

The reason for this is most probably because during shutdown we decrement 
many reference counts and free each memory block separately. Theoretically 
we could just exit without doing any freeing of memory but we have to find 
a solution for freeing resources (maybe directly in the resource list and 
not via reference counting).
If you can put together a short script which demonstrates the problem 
(without using external sources such as databases) then I will try and take 
a look at it and see if we need to improve the current code or go for a 
different approach.
Also, I hope you're running in non-debug mode because debug slows down 
memory allocation/freeing significantly.

Thanks,

Andi

At 10:35 AM 11/23/2001 +, Sam Liddicott wrote:
>I am using PHP for a system script to import TV listings to a database.
>
>It works well but creates 20,000  to 30,000 hash elements with various
>relationships and it *seems* to take exponentially longer for the script to
>actually stop running after it reaches the "exit" statement the more items
>there are.
>
>I also note that even though max execution time is set to zero and the
>script runs for a long time, I still get a max-execution error at 30 seconds
>after the script has been trying to exit (although the script runs for many
>minutes).  30 seconds is the timeout in the php.ini which I override with
>ini_set.
>
>I think this long shutdown time is PHP's per-page cleanup freeing all the
>objects, which is not so important if running as a CGI.
>
>Currently I am quitting with
>posix_kill(posix_getpid(),5)
>as it is pretty quick
>
>but I wondered if the per-page cleanup which is only important when running
>as an apache module could be disabled in cgi mode.
>
>Sam
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


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

[PHP-DEV] Bug #14196: segmentation fault committing nothing

[hegyvari]

From: [EMAIL PROTECTED]
Operating system: Redhat 6.2
PHP version:  4.0.6
PHP Bug Type: PostgreSQL related
Bug description:  segmentation fault committing nothing

Write something which makes an explicit commit before disconnecting from
postgres, but do not make any transactions. A notice is going to appear in
the postgresql log saying that a commit without transactions is made and
the same notice is going to appear in the apache error log as well. The
problem is that 5 times out of 10 Apache is also going to segfault. We had
this kind of "commit if no sql_error was recognized" in our system and
noticed the segfaults in the apache log. We removed the commit and all the
segfaults are gone from then on.

Postgresql 7.1.3. and PHP4.0.6.

 './configure' '--with-oci8' '--with-apache=/coca/install/apache_1.3.22/'
'--enable-sigchild' '--enable-track-vars' '--with-mysql'
'--with-pgsql=/usr/local/pgsql'


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


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

[PHP-DEV] Bug #14195 Updated: i think i found a bug in adding in PHP v4.0.5

[derick]

ID: 14195
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Math related
Operating System: win98se
PHP Version: 4.0.5
New Comment:

Not a bug. This how floating point arithmetic works. PHP can't do anything about it.
On a computer, floating point numbers are stored as the 'best possible' representation 
of it, and this does not always match the exact number.

Derick

Previous Comments:


[2001-11-23 07:03:25] [EMAIL PROTECTED]

");
}
?>
-
;extension=php_bz2.dll
;extension=php_ctype.dll
;extension=php_cpdf.dll
;extension=php_curl.dll
;extension=php_cybercash.dll
;extension=php_db.dll
;extension=php_dba.dll
;extension=php_dbase.dll
;extension=php_domxml.dll
;extension=php_dotnet.dll
;extension=php_exif.dll
;extension=php_fdf.dll
;extension=php_filepro.dll
extension=php_gd.dll
;extension=php_gettext.dll
;extension=php_hyperwave.dll
;extension=php_iconv.dll
;extension=php_ifx.dll
;extension=php_iisfunc.dll
;extension=php_imap.dll
;extension=php_ingres.dll
;extension=php_interbase.dll
;extension=php_java.dll
;extension=php_ldap.dll
;extension=php_mcrypt.dll
;extension=php_mhash.dll
;extension=php_ming.dll
;extension=php_mssql.dll
;extension=php_oci8.dll
;extension=php_openssl.dll
;extension=php_oracle.dll
;extension=php_pdf.dll
;extension=php_pgsql.dll
;extension=php_printer.dll
;extension=php_sablot.dll
;extension=php_snmp.dll
;extension=php_sybase_ct.dll
;extension=php_yaz.dll
extension=php_zlib.dll
-

i think i found a bug in adding in PHP v4.0.5
please, run this script above and take a look on lines from 444 to 1000 and then from 
2111 to 2500 in your browser.

my system: win98se, php v4.0.5, Apache 1.3.19

sorry for my english.
best wishes.
/k.wysiadly





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


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

Re: [PHP-DEV] Out of date modules etc

[James Moore]

> On Fri, 23 Nov 2001 14:32:49 -, James Moore wrote:
>
> >CCVS has now been dropped by redhat (it will be replaced by MCVE),
> >the module doesnt really seem to be supported either. With sablotron
> >going the same way (for different reasons though) perhaps we should
> >create a unsupported or and old directory in the pear c extension
> >repository for these modules to reside and move them out of php4/ext.
>
> I don't think we should "pollute" PEAR with such old crap. Why not
> remove them completely?

Because some people may still be using them and distributing them with PHP
seems rather pointless as if we do new people will start using them, if they
are in pear when the installer gets going they will still be available but
wont need to be distributed at all. They are also shown to be outdated
and/or redundant. PEAR is the PHP *Extension* and Application Repository, it
seems to be the fitting place for them.

- James


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

[PHP-DEV] Bug #14196 Updated: segmentation fault committing nothing

[hegyvari]

ID: 14196
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: PostgreSQL related
Operating System: Redhat 6.2
PHP Version: 4.0.6
New Comment:

To be clear, this is not a perfectly legal use of commit or rollback because a begin 
work statement should precede them. If begin work is used everything is fine.

Previous Comments:


[2001-11-23 08:26:29] [EMAIL PROTECTED]

an you try with latest RC and see if it works

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.




[2001-11-23 08:13:45] [EMAIL PROTECTED]

Write something which makes an explicit commit before disconnecting from postgres, but 
do not make any transactions. A notice is going to appear in the postgresql log saying 
that a commit without transactions is made and the same notice is going to appear in 
the apache error log as well. The problem is that 5 times out of 10 Apache is also 
going to segfault. We had this kind of "commit if no sql_error was recognized" in our 
system and noticed the segfaults in the apache log. We removed the commit and all the 
segfaults are gone from then on.

Postgresql 7.1.3. and PHP4.0.6.

 './configure' '--with-oci8' '--with-apache=/coca/install/apache_1.3.22/' 
'--enable-sigchild' '--enable-track-vars' '--with-mysql' 
'--with-pgsql=/usr/local/pgsql'







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


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

Re: [PHP-DEV] Out of date modules etc

[Martin Jansen]

On Fri, 23 Nov 2001 14:32:49 -, James Moore wrote:

>CCVS has now been dropped by redhat (it will be replaced by MCVE), 
>the module doesnt really seem to be supported either. With sablotron 
>going the same way (for different reasons though) perhaps we should 
>create a unsupported or and old directory in the pear c extension 
>repository for these modules to reside and move them out of php4/ext.

I don't think we should "pollute" PEAR with such old crap. Why not
remove them completely?

- Martin

-- 
  Martin Jansen, <[EMAIL PROTECTED]>
  http://www.martin-jansen.de/



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

RE: [PHP-DEV] CGI quick cleanup

[Sam Liddicott]

Here's a sample script that does most of the sorts of stuff I was doing
apart from database work.

Note how long it takes to exit after finishing.

#! /usr/bin/php -q
0) $this->ref=&new thingy($c-1);
  }
}

$stash=array();
$max=50;

$start=time();

for($i=0;$i<$max;$i++) {
  $r=rand(0,300);
  $stash[$r][]=&new thingy(rand(0,10));
  echo "\rUse: ".floor($i/$max*100)."% ";
}
echo "\n";

$mid=time();

$max=count($stash);
$c=0;
foreach(array_keys($stash) as $key) {
  unset($stash[$key]);
  $c++;
  echo "\rFree: ".floor($c/$max*100)."% ";
}
unset($stash);
echo "\n";

$done=time();

print "Use: ".($mid-$start)."\n";
print "Free: ".($done-$mid)."\n";


?>
 




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

[PHP-DEV] Out of date modules etc

[James Moore]

CCVS has now been dropped by redhat (it will be 
replaced by MCVE), the module doesnt really seem to be supported either. With 
sablotron going the same way (for different reasons though) perhaps we should 
create a unsupported or and old directory in the pear c extension repository for 
these modules to reside and move them out of php4/ext.
 
- James

[PHP-DEV] Bug #14197: please read example...

[9]

From: [EMAIL PROTECTED]
Operating system: Win32 (w2k)
PHP version:  4.0.6
PHP Bug Type: Session related
Bug description:  please read example...

1. standart php.ini, cookie disable, bug:
---php



---output-


--


2. set [url_rewriter.tags=""] in php.ini - no problem


3. Real example in my program (bug in html+js code):
---php--
document.writeln('http://bugs.php.net/?id=14197&edit=1


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

[PHP-DEV] Bug #14198: build error undefined symbol php_module

[roger . depreeuw]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.5.1
PHP version:  4.0.6
PHP Bug Type: Compile Failure
Bug description:  build error undefined symbol php_module

make failure using the following configure
configure activate -module=src/modules/php4/libphp.a

Error from make:
Undefined symbol php_module first referenced in file modules.o

ld: fatal: symbol referencing errors. No output written to httpd
-- 
Edit bug report at: http://bugs.php.net/?id=14198&edit=1


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

[PHP-DEV] Bug #14196 Updated: segmentation fault committing nothing

[mfischer]

ID: 14196
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: PostgreSQL related
Operating System: Redhat 6.2
PHP Version: 4.0.6
New Comment:

an you try with latest RC and see if it works

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.


Previous Comments:


[2001-11-23 08:13:45] [EMAIL PROTECTED]

Write something which makes an explicit commit before disconnecting from postgres, but 
do not make any transactions. A notice is going to appear in the postgresql log saying 
that a commit without transactions is made and the same notice is going to appear in 
the apache error log as well. The problem is that 5 times out of 10 Apache is also 
going to segfault. We had this kind of "commit if no sql_error was recognized" in our 
system and noticed the segfaults in the apache log. We removed the commit and all the 
segfaults are gone from then on.

Postgresql 7.1.3. and PHP4.0.6.

 './configure' '--with-oci8' '--with-apache=/coca/install/apache_1.3.22/' 
'--enable-sigchild' '--enable-track-vars' '--with-mysql' 
'--with-pgsql=/usr/local/pgsql'







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


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

[PHP-DEV] Bug #14195: i think i found a bug in adding in PHP v4.0.5

[kwysiadly]

From: [EMAIL PROTECTED]
Operating system: win98se
PHP version:  4.0.5
PHP Bug Type: Math related
Bug description:  i think i found a bug in adding in PHP v4.0.5

");
}
?>
-
;extension=php_bz2.dll
;extension=php_ctype.dll
;extension=php_cpdf.dll
;extension=php_curl.dll
;extension=php_cybercash.dll
;extension=php_db.dll
;extension=php_dba.dll
;extension=php_dbase.dll
;extension=php_domxml.dll
;extension=php_dotnet.dll
;extension=php_exif.dll
;extension=php_fdf.dll
;extension=php_filepro.dll
extension=php_gd.dll
;extension=php_gettext.dll
;extension=php_hyperwave.dll
;extension=php_iconv.dll
;extension=php_ifx.dll
;extension=php_iisfunc.dll
;extension=php_imap.dll
;extension=php_ingres.dll
;extension=php_interbase.dll
;extension=php_java.dll
;extension=php_ldap.dll
;extension=php_mcrypt.dll
;extension=php_mhash.dll
;extension=php_ming.dll
;extension=php_mssql.dll
;extension=php_oci8.dll
;extension=php_openssl.dll
;extension=php_oracle.dll
;extension=php_pdf.dll
;extension=php_pgsql.dll
;extension=php_printer.dll
;extension=php_sablot.dll
;extension=php_snmp.dll
;extension=php_sybase_ct.dll
;extension=php_yaz.dll
extension=php_zlib.dll
-

i think i found a bug in adding in PHP v4.0.5
please, run this script above and take a look on lines from 444 to 1000 and
then from 2111 to 2500 in your browser.

my system: win98se, php v4.0.5, Apache 1.3.19

sorry for my english.
best wishes.
/k.wysiadly
-- 
Edit bug report at: http://bugs.php.net/?id=14195&edit=1


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

[PHP-DEV] Bug #14194: no manual entry for apache_child_terminate

[samjam]

From: [EMAIL PROTECTED]
Operating system: All
PHP version:  4.0.6
PHP Bug Type: Documentation problem
Bug description:  no manual entry for apache_child_terminate

apache_child_terminate when called by a script running under apache's
mod_php will cause the current process serving the request and executing
the script to terminate once the request is complete.

This is useful if a script "knows" it has allocated a large ammount of
memory (which apache can't possibly give back to the system) and is likely
to be invoked again by another apache process soon leaving the system with
all apache processes hogging large ammounts of memory which they are never
likely to need again unless they get lucky and the same greedy script gets
assigned to one of it's previous processes.

Previously the fix was to set all apache processes to terminate after
serving only one request but now the greedy script can just call
apache_child_terminate(); instead - which actually has the effect of making
it look like that apache process has served past it's limit.
-- 
Edit bug report at: http://bugs.php.net/?id=14194&edit=1


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

Re: [PHP-DEV] CGI quick cleanup

[Markus Fischer]

On Fri, Nov 23, 2001 at 11:28:02AM -, Sam Liddicott wrote : 
> Hmm.  What do I need to do to get this documented then?

Oh well, talk so some phpdoc guy directly or just open a bug
report about it I guess?

- MArkus

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

RE: [PHP-DEV] CGI quick cleanup

[Sam Liddicott]

> -Original Message-
> From: Markus Fischer [mailto:[EMAIL PROTECTED]]
> Sent: 23 November 2001 11:16
> To: Sam Liddicott
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] CGI quick cleanup
> 
> 
> On Fri, Nov 23, 2001 at 11:01:03AM -, Sam Liddicott wrote : 
> > To solve THIS problem I added ap_child_terminate support to 
> php so you could
> > request apache to terminate after the page, though this 
> seems to have been
> > dropped in later releases.
> > The patch was accepted and did appear in at least one 
> release, I don't know
> > why it went.
> 
> I found this in php4/sapi/apache/php_apache.c :

[apache_child_terminate function deleted]

heh!  Thanks.

> However, it doesn't seem to be documented (couldn't find it
> in the manual). But yes, not really relevant because you're
> using a system script.

Hmm.  What do I need to do to get this documented then?

Thanks

Sam




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

[PHP-DEV] Bug #14138 Updated: date arithmetic scrambled

[mail-php . net]

ID: 14138
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Date/time related
Operating System: Debian GNU/Linux stable
PHP Version: 4.0.6
New Comment:

I'm curious, what do you think the problem was? libc6-dev and libc6 mismatch? I 
haven't kept a track of upgrades, although I believe libc6 hasn't been changed since 
long before Apache was compiled.

It also caused segfaults and other random wierdness in Apache.

The listed libc6 package (in previous report) isn't a current one on any Debian 
flavour.

potato: 2.1.3-19
woody: 2.2.4-5
If that sheds any light on the subject.

Previous Comments:


[2001-11-23 06:05:36] [EMAIL PROTECTED]

Nice, closing this one.



[2001-11-23 05:56:18] [EMAIL PROTECTED]

Recompiled 4.1.0RC3 using Apache 1.3.22.

Yes, mathematics now works correctly. Haven't tested fully yet, but the first glance 
looks like it works.



[2001-11-20 23:03:13] [EMAIL PROTECTED]

Linux 2.4.12 SMP
Debian potato libraries

Package: libc5
Version: 5.4.46-3

Package: libc6
Version: 2.2.3-9

Package: libc6-dev
Version: 2.2.3-9

bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
20 + -7
13





[2001-11-20 22:39:50] [EMAIL PROTECTED]

More info from _RainMkr_: "Running on woody, Linux 2.4.5, PHP 4.0.6"

What version is the Debian showing this problem?



[2001-11-20 22:35:38] [EMAIL PROTECTED]

Perhaps a problem with the Debian libraries, cannot confirm problem on PHP 4.0.6 under 
Solaris 2.8. Output of the code is correct in that machine and PHP version.

Code also tested by _RainMkr_ (from #php) using PHP 4.0.6 under Linux 2.4.5

Need feedback on whether other numeric programs have similar problems under that 
version of Debian.



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/?id=14138


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


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

Re: [PHP-DEV] CGI quick cleanup

[Markus Fischer]

On Fri, Nov 23, 2001 at 11:01:03AM -, Sam Liddicott wrote : 
> To solve THIS problem I added ap_child_terminate support to php so you could
> request apache to terminate after the page, though this seems to have been
> dropped in later releases.
> The patch was accepted and did appear in at least one release, I don't know
> why it went.

I found this in php4/sapi/apache/php_apache.c :

/* {{{ proto string child_terminate()
   Get and set Apache request notes */
PHP_FUNCTION(apache_child_terminate)
{
#ifndef MULTITHREAD
if (AP(terminate_child)) {
ap_child_terminate( ((request_rec *)SG(server_context))
);
} else { /* tell them to get lost! */
php_error(E_WARNING, "apache.child_terminate is
disabled");
}
#else
php_error(E_WARNING, "apache_child_terminate() is not
supported in this build");
#endif
}
/* }}} */

However, it doesn't seem to be documented (couldn't find it
in the manual). But yes, not really relevant because you're
using a system script.

- Markus

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

[PHP-DEV] Bug #14189 Updated: GD 2.0.1 compiling error

[raw]

ID: 14189
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Compile Failure
Operating System: Red Hat 6.2
PHP Version: 4.0.6
New Comment:

I am newbie, can you explain to do it or a tutorial step by step?

Thanks

Previous Comments:


[2001-11-22 18:55:56] [EMAIL PROTECTED]

fixed in cvs




[2001-11-22 18:17:23] [EMAIL PROTECTED]

Hi. I trying recompiling new version gd with php 4.0.6 e obtain error message:

Making all in gd
make[2]: Entering directory `/home/raw/php-4.0.6/ext/gd'
make[3]: Entering directory `/home/raw/php-4.0.6/ext/gd'
gcc  -I. -I/home/raw/php-4.0.6/ext/gd -I/home/raw/php-4.0.6/main -I/home/raw/php-4.0.6 
-I/home/raw/apache_1.3.19/src/include -I/home/raw/apache_1.3.19/src/os/unix 
-I/home/raw/php-4.0.6/Zend -I/home/raw/php-4.0.6/ext/mysql/libmysql 
-I/home/raw/php-4.0.6/ext/xml/expat/xmltok 
-I/home/raw/php-4.0.6/ext/xml/expat/xmlparse -I/home/raw/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c gd.c && touch gd.lo
gd.c:95: conflicting types for `gdIOCtx'
/usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx'
gd.c: In function `php_if_imagecreatefromgif':
gd.c:1209: `gdImageCreateFromGif' undeclared (first use in this function)
gd.c:1209: (Each undeclared identifier is reported only once
gd.c:1209: for each function it appears in.)
gd.c: In function `php_if_imagegif':
gd.c:1404: `gdImageGif' undeclared (first use in this function)

My line to configure command is: 
./configure --with-gd --with-jpeg-dir=../jpeg-6b/ --with-png-dir=../libpng-1.0.11/ 
--with-mysql --with-apache=../apache_1.3.19/ --enable-track-vars 
--with-zlib-dir=../zlib-1.1.3/

Help me?
Regards





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


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

[PHP-DEV] Bug #14138 Updated: date arithmetic scrambled

[mfischer]

ID: 14138
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Date/time related
Operating System: Debian GNU/Linux stable
PHP Version: 4.0.6
New Comment:

Nice, closing this one.

Previous Comments:


[2001-11-23 05:56:18] [EMAIL PROTECTED]

Recompiled 4.1.0RC3 using Apache 1.3.22.

Yes, mathematics now works correctly. Haven't tested fully yet, but the first glance 
looks like it works.



[2001-11-20 23:03:13] [EMAIL PROTECTED]

Linux 2.4.12 SMP
Debian potato libraries

Package: libc5
Version: 5.4.46-3

Package: libc6
Version: 2.2.3-9

Package: libc6-dev
Version: 2.2.3-9

bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
20 + -7
13





[2001-11-20 22:39:50] [EMAIL PROTECTED]

More info from _RainMkr_: "Running on woody, Linux 2.4.5, PHP 4.0.6"

What version is the Debian showing this problem?



[2001-11-20 22:35:38] [EMAIL PROTECTED]

Perhaps a problem with the Debian libraries, cannot confirm problem on PHP 4.0.6 under 
Solaris 2.8. Output of the code is correct in that machine and PHP version.

Code also tested by _RainMkr_ (from #php) using PHP 4.0.6 under Linux 2.4.5

Need feedback on whether other numeric programs have similar problems under that 
version of Debian.



[2001-11-20 04:47:13] [EMAIL PROTECTED]


Works fine for me, can you try the RC from www.php.net/~zeev/php-4.1.0RC3.tar.gz ?

Derick



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/?id=14138


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


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

Re: [PHP-DEV] CGI quick cleanup

[Edin Kadribasic]

> > I have noticed the same problem with a scipt that used a very large
array
> > (~160 MB). The script run time was around 35 seconds, while it took over
4
> > minutes to shut down! Same amount of time was used in trying to unset()
the
> > array.
>
> [wild guess]
> probably the memory deallocation is the one expensive here.

Probably true. But there is a big performance problem here, and I think it
should be looked at. I cannot belive that 4 minutes to deallocte 160 MB ram
is the best we can do on a 1 GHz machine with 1GB ram.

> BTW, don't use large arrays in PHP as Apache module cause when the process
> grows requesting more memory (brk(2)) it cannot release it back to the
> system (because the httpd process is still running).

I'm aware of this, but this was command line script so that was not a
problem.

Edin


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

Re: [PHP-DEV] CGI quick cleanup

[Markus Fischer]

On Fri, Nov 23, 2001 at 11:50:17AM +0100, Edin Kadribasic wrote : 
> I have noticed the same problem with a scipt that used a very large array
> (~160 MB). The script run time was around 35 seconds, while it took over 4
> minutes to shut down! Same amount of time was used in trying to unset() the
> array.

Hmm .. your script... is this something which other can
easily reproduce with the same datainput or is it specific
because of the database, the content, etc?

If the latter, can you in more detail describe the how much
data and the structure of the data put into the arary with
takes up 160mb?

Maybe we can track something down the available profilers.

- Markus

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

RE: [PHP-DEV] CGI quick cleanup

[Sam Liddicott]

> -Original Message-
> From: Teodor Cimpoesu [mailto:[EMAIL PROTECTED]]
> Sent: 23 November 2001 10:54
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] CGI quick cleanup
> 
> 
> Hi Edin!
> On Fri, 23 Nov 2001, Edin Kadribasic wrote:
> 
> > I have noticed the same problem with a scipt that used a 
> very large array
> > (~160 MB). The script run time was around 35 seconds, while 
> it took over 4
> > minutes to shut down! Same amount of time was used in 
> trying to unset() the
> > array.
> 
> [wild guess]
> probably the memory deallocation is the one expensive here.
> 
> BTW, don't use large arrays in PHP as Apache module cause 
> when the process
> grows requesting more memory (brk(2)) it cannot release it back to the
> system (because the httpd process is still running).

To solve THIS problem I added ap_child_terminate support to php so you could
request apache to terminate after the page, though this seems to have been
dropped in later releases.
The patch was accepted and did appear in at least one release, I don't know
why it went.

But our problem is not as an apache module but as a system script, using php
-q

Sam




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

[PHP-DEV] Bug #14138 Updated: date arithmetic scrambled

[mail-php . net]

ID: 14138
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Operating System: Debian GNU/Linux stable
PHP Version: 4.0.6
New Comment:

Recompiled 4.1.0RC3 using Apache 1.3.22.

Yes, mathematics now works correctly. Haven't tested fully yet, but the first glance 
looks like it works.

Previous Comments:


[2001-11-20 23:03:13] [EMAIL PROTECTED]

Linux 2.4.12 SMP
Debian potato libraries

Package: libc5
Version: 5.4.46-3

Package: libc6
Version: 2.2.3-9

Package: libc6-dev
Version: 2.2.3-9

bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
20 + -7
13





[2001-11-20 22:39:50] [EMAIL PROTECTED]

More info from _RainMkr_: "Running on woody, Linux 2.4.5, PHP 4.0.6"

What version is the Debian showing this problem?



[2001-11-20 22:35:38] [EMAIL PROTECTED]

Perhaps a problem with the Debian libraries, cannot confirm problem on PHP 4.0.6 under 
Solaris 2.8. Output of the code is correct in that machine and PHP version.

Code also tested by _RainMkr_ (from #php) using PHP 4.0.6 under Linux 2.4.5

Need feedback on whether other numeric programs have similar problems under that 
version of Debian.



[2001-11-20 04:47:13] [EMAIL PROTECTED]


Works fine for me, can you try the RC from www.php.net/~zeev/php-4.1.0RC3.tar.gz ?

Derick



[2001-11-20 04:43:47] [EMAIL PROTECTED]

There seems to be some voodoo in this script ...

for ( $i = -7 ; $i < 28 ; $i ++ ) {
$day = date('d');
print "\ndate is $day ";
$day = $day + $i;
print " after adding $i is $day ";
}

And output ends up looking like so:

date is 20  after adding -7 is 135122101 






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


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

Re: [PHP-DEV] CGI quick cleanup

[Teodor Cimpoesu]

Hi Edin!
On Fri, 23 Nov 2001, Edin Kadribasic wrote:

> I have noticed the same problem with a scipt that used a very large array
> (~160 MB). The script run time was around 35 seconds, while it took over 4
> minutes to shut down! Same amount of time was used in trying to unset() the
> array.

[wild guess]
probably the memory deallocation is the one expensive here.

BTW, don't use large arrays in PHP as Apache module cause when the process
grows requesting more memory (brk(2)) it cannot release it back to the
system (because the httpd process is still running).

-- teodor

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

Re: [PHP-DEV] CGI quick cleanup

[Edin Kadribasic]

I have noticed the same problem with a scipt that used a very large array
(~160 MB). The script run time was around 35 seconds, while it took over 4
minutes to shut down! Same amount of time was used in trying to unset() the
array.

Edin
- Original Message -
From: "Sam Liddicott" <[EMAIL PROTECTED]>
To: "Sam Liddicott" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, November 23, 2001 11:41 AM
Subject: RE: [PHP-DEV] CGI quick cleanup


> I should add that without the kill -5 it takes longer for the script to
> finally exit than it took to execute!
>
> Sam
>
> > -Original Message-
> > From: Sam Liddicott [mailto:[EMAIL PROTECTED]]
> > Sent: 23 November 2001 10:35
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] CGI quick cleanup
> >
> >
> > I am using PHP for a system script to import TV listings to a
> > database.
> >
> > It works well but creates 20,000  to 30,000 hash elements with various
> > relationships and it *seems* to take exponentially longer for
> > the script to
> > actually stop running after it reaches the "exit" statement
> > the more items
> > there are.
> >
> > I also note that even though max execution time is set to zero and the
> > script runs for a long time, I still get a max-execution
> > error at 30 seconds
> > after the script has been trying to exit (although the script
> > runs for many
> > minutes).  30 seconds is the timeout in the php.ini which I
> > override with
> > ini_set.
> >
> > I think this long shutdown time is PHP's per-page cleanup
> > freeing all the
> > objects, which is not so important if running as a CGI.
> >
> > Currently I am quitting with
> > posix_kill(posix_getpid(),5)
> > as it is pretty quick
> >
> > but I wondered if the per-page cleanup which is only
> > important when running
> > as an apache module could be disabled in cgi mode.
> >
> > Sam



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

RE: [PHP-DEV] CGI quick cleanup

[Sam Liddicott]

I should add that without the kill -5 it takes longer for the script to
finally exit than it took to execute!

Sam

> -Original Message-
> From: Sam Liddicott [mailto:[EMAIL PROTECTED]]
> Sent: 23 November 2001 10:35
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] CGI quick cleanup
> 
> 
> I am using PHP for a system script to import TV listings to a 
> database.
> 
> It works well but creates 20,000  to 30,000 hash elements with various
> relationships and it *seems* to take exponentially longer for 
> the script to
> actually stop running after it reaches the "exit" statement 
> the more items
> there are.
> 
> I also note that even though max execution time is set to zero and the
> script runs for a long time, I still get a max-execution 
> error at 30 seconds
> after the script has been trying to exit (although the script 
> runs for many
> minutes).  30 seconds is the timeout in the php.ini which I 
> override with
> ini_set.
> 
> I think this long shutdown time is PHP's per-page cleanup 
> freeing all the
> objects, which is not so important if running as a CGI.
> 
> Currently I am quitting with 
> posix_kill(posix_getpid(),5)
> as it is pretty quick
> 
> but I wondered if the per-page cleanup which is only 
> important when running
> as an apache module could be disabled in cgi mode.
> 
> Sam
> 
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: 
> [EMAIL PROTECTED]
> 




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

[PHP-DEV] CGI quick cleanup

[Sam Liddicott]

I am using PHP for a system script to import TV listings to a database.

It works well but creates 20,000  to 30,000 hash elements with various
relationships and it *seems* to take exponentially longer for the script to
actually stop running after it reaches the "exit" statement the more items
there are.

I also note that even though max execution time is set to zero and the
script runs for a long time, I still get a max-execution error at 30 seconds
after the script has been trying to exit (although the script runs for many
minutes).  30 seconds is the timeout in the php.ini which I override with
ini_set.

I think this long shutdown time is PHP's per-page cleanup freeing all the
objects, which is not so important if running as a CGI.

Currently I am quitting with 
posix_kill(posix_getpid(),5)
as it is pretty quick

but I wondered if the per-page cleanup which is only important when running
as an apache module could be disabled in cgi mode.

Sam




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

[PHP-DEV] status of openssl fn in php 4.1

[Pavol Cvengros]

Hi all.

please I need to know the status (functionality) of openssl support in 
next version of php ( php-4.1 ??? )
(because I work on new free national CA)



PS: please reply to [EMAIL PROTECTED]
PS1: sorry for my bad english
-- 
---[Signature]---
Name:   Pavol Cvengros
Position:   Software Department, System Engineer
Company:Profinet.sk, a.s.
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]

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

[PHP-DEV] Bug #14193: I compile 4.2.0-dev well but when startup Apache not run

[scalero]

From: [EMAIL PROTECTED]
Operating system: tru64 v.5.1
PHP version:  4.0.6
PHP Bug Type: OCI8 related
Bug description:  I compile 4.2.0-dev well but when startup Apache not run

NLS_LANG=SPANISH_SPAIN.WE8ISO8859P1
ORACLE_BASE=/u01/app/oracle
ORACLE_PATH=/u01/app/oracle/product/8.1.7/bin
LOGNAME=root
when I compile PHP/4.2.0-dev like DSO in tru64 v.5.1 with the
following variables of surroundings:


TEMPDIR=/u01/temp
ORACLE_SID=dborapre
GWSOURCE=telnet
ORACLE_OWNER=oracle
USER=root
ORACLE_DOC=/u01/app/oracle/product/8.1.7/doc
SHELL=/bin/ksh
ORACLE_TERM=vt220
ORA_NLS33=/u01/app/oracle/product/8.1.7/ocommon/nls/admin/data
HOME=/
LD_LIBRARY_PATH=/u01/app/oracle/product/8.1.7/lib
TERM=vt220
ORACLE_HOME=/u01/app/oracle/product/8.1.7


then I execute:

# ./configure --enable-ftp --with-gettext
--with-imap=/data/sebas/programs/imap-uw --with-oci8
--with-apxs=/usr/opt/IAE550/usr/internet/httpd/bin/apxs
--enable-dependency-tracking
#make
#make install

and when I start Apache:

Cannot load /usr/internet/httpd/libexec/libphp4.so into server: dlopen:
/usr/internet/httpd/libexec/libphp4.so: symbol "OCILobIsTemporary"
unresolved

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


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

[PHP-DEV] Bug #14192: Disable Error Control Operator

[c . green]

From: [EMAIL PROTECTED]
Operating system: Solaris
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  Disable Error Control Operator

Hey guys,

What I'd like is some sort of config variable to temporarily disable the
Error Control Operator (@foo()).

It would be great to be able to pop a flag in an htaccess (which I can
leave out of the cvs tree)  and get error messages for
development/debugging.  

Cheerio,

Cameron Green

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


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

[PHP-DEV] Re: [PEAR-DEV] PHPDoc Development Status

[Ol]

On Thu, 22 Nov 2001 22:17:18 +0100
[EMAIL PROTECTED] wrote:

> I've written a PHP-2-XML converter which is sitting directly on the
> Zend-parser. This gives us more speed and more accuracy.

Difficult to do better in fact ... ;)
 
> It has been written because Ulf Wendel convinced me to do it by
> delivering a few pizzas. 

:))

> If someone wants to test it, download it from http://weigon.dyndns.org/

Yeap it works fine :)
Some minor bugfixes i've find tonight (diff -u at bottom)

> It is a php-extension which requires some patches to the Zend engine. If
> someone tests it, don't give up to early. The ext has been written for
> 4.0.4pl1 or the like and won't compile with the latest php as the Zend
> core has changed.

At least it still work with 4.0.6

> Currently missing is the PHPDoc part (the php code) which can handle
> XML.

What to you thing about a double output for this code :
- on a side can generate standart HTML output like 'classical' phpdoc
- on the other a docbook output.

It could be a good way to obtain more easily pear's enduser doc. Even if
the docbook output surely need corrections it could be anyway a nice
starting point... 




--- old_phpdoc.cFri Nov 23 08:58:31 2001
+++ phpdoc.cFri Nov 23 08:47:44 2001
@@ -17,6 +17,7 @@
+--+
  */
 
+
 #include "php.h"
 #include "php_ini.h"
 #include "php_phpdoc.h"
@@ -488,6 +489,14 @@
PHPDOC_STRCAT(new_string, "/>");
st.pos--;
break;
+   case T_INCLUDE:
+   case T_INCLUDE_ONCE:
+   case T_REQUIRE:
+   case T_REQUIRE_ONCE:
+   zend_sprintf(buffer, "\"/>\n");
+   PHPDOC_STRCAT(new_string, buffer);
+   st.pos--;
+   break;
}
break;
case '=':
@@ -530,6 +539,14 @@
}
break;
case ',':
+   switch (find_something(st.stack, st.pos)) {
+   case T_FUNCTION_PARAM:
+   zend_sprintf(buffer, "/>");
+   PHPDOC_STRCAT(new_string, buffer);
+   st.pos--;
+   break;
+   }
+   case T_ARRAY:
switch (find_something(st.stack, st.pos)) {
case T_FUNCTION_PARAM:
zend_sprintf(buffer, "/>");


--
Olivier Courtin

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