[PHP-DEV] Bug #11796 Updated: get_meta_tags doesn't work when the title tag consists of single quote

[teocl]

ID: 11796
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: Unknown/Other Function
Operating system: Linux
PHP Version: 4.0.5
Description: get_meta_tags doesn't work when the title tag consists of single quote

Hi, have another question.
Is this bug fixed in 4.0.6?
If so, I would rather upgrade my php to 4.0.6.

Thanks.




Previous Comments:
---

[2001-07-03 03:03:40] [EMAIL PROTECTED]

nm, wrong entry

---

[2001-07-03 03:01:34] [EMAIL PROTECTED]

>From the ChangeLog:

2001-03-06  Sean Bright  <[EMAIL PROTECTED]>

* ext/standard/file.c: Typo.

* ext/standard/file.c:
get_meta_tags now allows attributes that are not quoted as well as those
that are.  It follows the HTML 4.01 specification for attribute values
outlined here -> http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2

You could have checked this yourself BTW.

Derick

---

[2001-07-03 02:12:28] [EMAIL PROTECTED]

Hi, have another question.
Is this bug fixed in 4.0.6?
If so, I would rather upgrade my php to 4.0.6.

Thanks.




---

[2001-07-02 04:12:45] [EMAIL PROTECTED]

Either grab a snapshot form snaps.php.net or follow the instructions on getting the 
CVS version on: www.php.net/anoncvs.php

Derick

---

[2001-07-02 04:11:02] [EMAIL PROTECTED]

http://www.php.net/anoncvs.php


---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=11796


-- 
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 #11851: Failure at php_include

[jan . suchanek]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.1 (2.4.2
PHP version:  4.0.6
PHP Bug Type: PHP options/info functions
Bug description:  Failure at php_include

Using Apache 1.3.20 (DSO) and PHP 4.0.6 as a module.

If a make a *.php file on Linux system, it works, but when I copy a *.php file from 
W2000, it returns:
Warning: Failed opening '/usr/local/apache/htdocs/index.php' for inclusion 
(include_path='.:/usr/local/lib/php') in Unknown on line 0
when loading.

Is any problem with different encoding?


-- 
Edit Bug report at: http://bugs.php.net/?id=11851&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 #11851 Updated: Failure at php_include

[jan . suchanek]

ID: 11851
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: PHP options/info functions
Operating system: RedHat Linux 7.1 (2.4.2
PHP Version: 4.0.6
Description: Failure at php_include

Thanx
I have changed permissions from -rwxrwx--- to -rwxrwxr-- and it semms O.K.

Previous Comments:
---

[2001-07-03 04:04:39] [EMAIL PROTECTED]

Possibly permissions, can you check this?

Derick

---

[2001-07-03 03:59:30] [EMAIL PROTECTED]

Using Apache 1.3.20 (DSO) and PHP 4.0.6 as a module.

If a make a *.php file on Linux system, it works, but when I copy a *.php file from 
W2000, it returns:
Warning: Failed opening '/usr/local/apache/htdocs/index.php' for inclusion 
(include_path='.:/usr/local/lib/php') in Unknown on line 0
when loading.

Is any problem with different encoding?

---


Full Bug description available at: http://bugs.php.net/?id=11851


-- 
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 #11851 Updated: Failure at php_include

[derick]

ID: 11851
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: PHP options/info functions
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Bogus: User error

Previous Comments:
---

[2001-07-03 04:21:33] [EMAIL PROTECTED]

Thanx
I have changed permissions from -rwxrwx--- to -rwxrwxr-- and it semms O.K.

---

[2001-07-03 04:04:39] [EMAIL PROTECTED]

Possibly permissions, can you check this?

Derick

---

[2001-07-03 03:59:30] [EMAIL PROTECTED]

Using Apache 1.3.20 (DSO) and PHP 4.0.6 as a module.

If a make a *.php file on Linux system, it works, but when I copy a *.php file from 
W2000, it returns:
Warning: Failed opening '/usr/local/apache/htdocs/index.php' for inclusion 
(include_path='.:/usr/local/lib/php') in Unknown on line 0
when loading.

Is any problem with different encoding?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11851&edit=2


-- 
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] Re: [Zend Engine 2] substr changes

[Thies C. Arntzen]

On Tue, Jul 03, 2001 at 03:07:37AM +0200, Andre Langhorst wrote:
> >Just one thing I did want to point out - this has nothing to do with 
> >Zend 3 or whatever.  I oppose this feature not because lack of time to 
> >implement it or because it's difficult to implement, but because it 
> >doesn't belong in PHP.  Personally, I wouldn't want to see it even in 
> >PHP 7.0...
> 
> 
> although disagreeing, I agree in completely skipping this then, as 
> previously proposed...
> 
> what about operator overloading in exchange? ;)

i think that's even worse.

i can happily life without it!
tc

-- 
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] foreach behavior and error suppression (@foo)

[Stanislav Malyshev]

DB>> There are several open feature requests in the bug system to
DB>> allow the use of @ to suppress warnings when using a non array
DB>> with foreach.  What's the status of this?  Is this a "hell no!",
DB>> "not possible with the current state of the code" or a "when we
DB>> get around to it"?

Well, if you are around this with @, why not with if(is_array())?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115




-- 
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] foreach behavior and error suppression (@foo)

[derick]

On Tue, 3 Jul 2001, Stanislav Malyshev wrote:

> Well, if you are around this with @, why not with if(is_array())?

What looks better and is easier to read?:

1.:
if (is_array($ar)) {
foreach ($ar as $element) {
}
}

2.:
@foreach ($ar as $element) {
}

I clearly see some usefulness here. It makes code less cluttered. However,
as foreach is a language construct, I do not think the @ should work on
it. But, making foreach threat NULL variables as empty arrays, would be a
goof thing IMO.

regards,
Derick


-- 
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 #4630 Updated: Segmentation fault(coredump) in apache startup

[derick]

ID: 4630
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0.6RC2
Assigned To: 
Comments:

Do you try it with the HEAD branch (From CVS) already?

Previous Comments:
---

[2001-06-12 19:00:30] [EMAIL PROTECTED]

According to Sascha, the fixes were not put into
the 4.0.6 branch, they are only in the HEAD branch
of the CVS. Could you please check it out? And let
us know if this really is fixed or not.

--Jani


---

[2001-06-04 19:26:50] [EMAIL PROTECTED]

I tried compiling php-4.0.6RC2, but I seem to be getting the old results again. 
Interestingly, I no longer see mention of "httpd.exp" (as opposed to 
php4-200105210845, which had addressed that problem), so apparently we're back to the 
original behavior-- it compiles, but I get the same segfault. Were the earlier changes 
(see 2001-05-18) backed out for some reason?

$ grep -l "httpd.exp" php-4.0.6RC2/*

$ grep -l "httpd.exp" php4-200105210845/*
php4-200105210845/config.log
php4-200105210845/configure


Here's my compilation process-- I don't think anything has changed:

export CC="cc_r"
export CFLAGS="-g -ma"
export LDFLAGS=""

./configure --enable-c9x-inline 
--prefix=/local/www/php 
--with-apxs=/local/www/bin/apxs 
--with-config-file-path=/local/www/php 
--without-mysql
...

$ make
...
/bin/sh /local/php/src/php-4.0.6RC2/libtool --silent --mode=link cc_r  -I. 
-I/local/php/src/php-4.0.6RC2/ -I/local/php/src/php-4.0.6RC2/main 
-I/local/php/src/php-4.0.6RC2 -I/local/www/include -I/local/php/src/php-4.0.6RC2/Zend 
-I/local/php/src/php-4.0.6RC2/ext/xml/expat/xmltok 
-I/local/php/src/php-4.0.6RC2/ext/xml/expat/xmlparse 
-I/local/php/src/php-4.0.6RC2/TSRM  -DAIX=43 -DAIX_BIND_PROCESSOR -DUSE_HSREGEX 
-DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -ma   -o libphp4.la -rpath 
/local/php/src/php-4.0.6RC2/libs -avoid-version   stub.lo  Zend/libZend.la  
sapi/apache/libsapi.la  main/libmain.la  regex/libregex.la  ext/pcre/libpcre.la 
ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la 
ext/xml/libxml.la  TSRM/libtsrm.la -ldl -lcrypt -lbind -lm -ldl
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_language_parser.lo contains an 
incorrect file suffix
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_ini_parser.lo contains an 
incorrect file suffix
cc_r: 1501-218 file .libs/libphp4.lax/libZend.al/zend_alloc.lo contains an incorrect 
file suffix
...
cc_r: 1501-218 file .libs/libphp4.lax/libtsrm.al/tsrm_virtual_cwd.lo contains an 
incorrect file suffix
Target "all-p" is up to date.
Making all in pear
Target "all" is up to date.
Target "all" is up to date.

$ su

# /usr/sbin/slibclean # force unload of dynamic libs with usage count of 0 on AIX

# make install
...

# /local/www/bin/httpd -X
Segmentation fault(coredump)

# dbx httpd core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in php_save_umask at line 117 in file "" ($t1)
could not read "mod_php4.c"
(dbx) where
php_save_umask(), line 117 in "mod_php4.c"
php_create_dir(p = 0x2001ef28, dummy = (nil)), line 601 in "mod_php4.c"
ap_single_module_configure(0x2001ef28, 0x2001ef50, 0x200897a0), line 1500 in 
"http_config.c"
load_module(0x2ff22938, 0x0, 0x2001f748, 0x2001f758), line 282 in "mod_so.c"
invoke_cmd(0x2000f5e0, 0x2ff22938, 0x0, 0x2ff20910), line 818 in "http_config.c"
unnamed block $b14, line 1008 in "http_config.c"
ap_handle_command(0x2ff22938, 0x2001f480, 0x2ff208e0), line 1008 in "http_config.c"
unnamed block $b16, line 1022 in "http_config.c"
ap_srm_command_loop(0x2ff22938, 0x2001f480), line 1022 in "http_config.c"
ap_process_resource_config(0x2001ef50, 0x2001f608, 0x2001ef28, 0x20022f68), line 1202 
in "http_config.c"
ap_read_config(0x2001ef28, 0x20022f68, 0x200052a0), line 1481 in "http_config.c"
http_main.main(argc = 2, argv = 0x2ff22b30), line 4955 in "http_main.c"
(dbx) quit

# gdb httpd
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14 (rs6000-ibm-aix3.2.5), Copyright 1995 Free Software Foundation, Inc...
(gdb) r
Starting program: /local/www/bin/httpd 
"/usr/lib/libpthreads.a": not in executable format: File format not recognized.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xd0aec98c in __dbsubn ()
(gdb) where
#0  0xd0aec98c in __dbsubn ()
#1  0xd0aeaf38 in __dbsubn ()
#2  0x10034108 in ap_single_module_configure (p=0x2001ef28, s=0x2001ef50, 
m=0x200897a0) at http_config.c:1500
#3  0x10068760 in load_module (cmd=0x2ff22918

[PHP-DEV] Bug #7252 Updated: Intermittent Segfault when running sybase_connect or sybase_pconnect

[derick]

ID: 7252
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Sybase (dblib) related
Operating system: 
PHP Version: 4.0.3pl1
Assigned To: 
Comments:

Can you confirm this is still a problem with PHP 4.0.6?

Derick

Previous Comments:
---

[2001-06-12 17:39:10] [EMAIL PROTECTED]

Please try PHP 4.0.6RC3 from http://www.php.net/~andi/php-4.0.6RC3.tar.gz
and condigure it using also --enable-debug to get 
useful backtrace.

--Jani


---

[2000-10-16 12:43:26] [EMAIL PROTECTED]

gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x4006036c in dbsetlname () from /usr/local/sybase-11.9.2/lib/libsybdb.so
(gdb) bt
#0  0x4006036c in dbsetlname () from /usr/local/sybase-11.9.2/lib/libsybdb.so
#1  0x80f7080 in php_rshutdown_sybase ()
#2  0x80f747e in php_if_sybase_connect ()
#3  0x812f21c in execute ()
#4  0x810bdf8 in zend_execute_scripts ()
#5  0x80aa091 in php_execute_script ()
#6  0x81158d9 in apache_php_module_main ()
#7  0x80a7d3b in send_php ()
#8  0x80a7d68 in send_parsed_php ()
#9  0x81392f3 in ap_invoke_handler ()
#10 0x814cc99 in ap_some_auth_required ()
#11 0x814ccfc in ap_process_request ()
#12 0x814450e in ap_child_terminate ()
#13 0x81446bc in ap_child_terminate ()
#14 0x8144819 in ap_child_terminate ()
#15 0x8144e46 in ap_child_terminate ()
#16 0x81455e3 in main ()
#17 0x401579cb in __libc_start_main (main=0x814528c , argc=4,
argv=0xbb34, init=0x8078c9c <_init>, fini=0x81e511c <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbb2c)
at ../sysdeps/generic/libc-start.c:92

Apache 1.3.12 with mod_ssl 2.2.6 and OpenSSL 2.6.6
PHP configure:
./configure --with-apache=../apache_1.3.12 --with-sybase=/usr/local/sybase-11.9.2 
--enable-track-vars

Apache configure:
./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a 
--enable-module=ssl


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7252&edit=2


-- 
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 #8346 Updated: DB2 CLI do not support SQL_CURSOR_DYNAMIC

[derick]

ID: 8346
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Suspended
Bug Type: ODBC related
Operating system: 
PHP Version: 4.0.3pl1
Assigned To: 
Comments:

No feedback

Previous Comments:
---

[2001-06-11 10:14:15] [EMAIL PROTECTED]

this patch is a really bad idea.  

hopefully i'll have a better solution for you in the near future... i'm awaiting patch 
confirmation from some others before commiting it.

---

[2000-12-21 03:09:55] [EMAIL PROTECTED]

The change above have effect of disabling scrolling through lists. However retriving 
one record is not a problem.

Here's the script which demonstrates the bug:



Output as follows:

test.php(9) : Warning - SQL error: [IBM][CLI Driver][DB2/6000] SQL0954C  Not enough 
storage is available in the application h
eap to process the statement.  SQLSTATE=57011
, SQL state 57011 in SQLExecDirect
test.php(11) : Warning - Supplied argument is not a valid ODBC result resource
test.php(15) : Warning - Supplied argument is not a valid ODBC result resource


---

[2000-12-21 01:48:35] [EMAIL PROTECTED]

When you execute a php script which uses odbc_exec for more than 946 times (milage may 
vary), the following error message is returned:

Warning - SQL error: [IBM][CLI Driver][DB2/6000] SQL0954C  Not enough storage is 
available in the application heap to process the statement.  SQLSTATE=57011

The following information is discovered in IBM DB2 CLI manual:

SQL_ATTR_CURSOR_TYPE (DB2 CLI v2) 
A 32-bit integer value that specifies the cursor type. The supported values are: 

SQL_CURSOR_FORWARD_ONLY = The cursor only scrolls forward. 
SQL_CURSOR_STATIC = The data in the result set is static. This is the default. 
SQL_CURSOR_KEYSET_DRIVEN = DB2 CLI supports a pure keyset cursor. The SQL_KEYSET_SIZE 
statement attribute is ignored. To limit the size of the keyset the application must 
limit the size of the result set by setting the SQL_ATTR_MAX_ROWS attribute to a value 
other than 0. 
This option cannot be specified for an open cursor. 

If the specified cursor type is not supported by the data source, CLI substitutes a 
different cursor type and returns SQLSTATE 01S02 (Option value changed). For a mixed 
or dynamic cursor, CLI substitutes, in order, a keyset-driven or static cursor. 

Note: The following value has also been defined by ODBC, but is not supported by DB2 
CLI: 
SQL_CURSOR_DYNAMIC 
If this values is used, DB2 CLI sets the statement attribute to SQL_CURSOR_STATIC 
SQL_CURSOR_FORWARD_ONLY and returns SQLSTATE 01S02 (Option value changed). In this 
case the application should call SQLGetStmtAttr() to query the actual value. 
 
The quick work around is to edit ext/odbc/php_odbc.c, and disable SQL_CURSOR_DYNAMIC, 
and to change all instances of SQL_CURSOR_DYNAMIC to SQL_CURSOR_FORWARD_ONLY.  It 
appear that DB2/CLI exhibits memory leak when statement type is set to 
SQL_CURSOR_DYNAMIC.

The diff follows:

--- php_odbc.c.orig Thu Dec 21 00:44:49 2000
+++ php_odbc.c  Thu Dec 21 01:00:30 2000
@@ -354,7 +354,9 @@
REGISTER_LONG_CONSTANT("SQL_CURSOR_TYPE", SQL_CURSOR_TYPE, CONST_PERSISTENT | 
CONST_CS);
REGISTER_LONG_CONSTANT("SQL_CURSOR_FORWARD_ONLY", SQL_CURSOR_FORWARD_ONLY, 
CONST_PERSISTENT | CO
NST_CS);
REGISTER_LONG_CONSTANT("SQL_CURSOR_KEYSET_DRIVEN", SQL_CURSOR_KEYSET_DRIVEN, 
CONST_PERSISTENT | 
CONST_CS);
+#ifndef HAVE_IBMDB2
REGISTER_LONG_CONSTANT("SQL_CURSOR_DYNAMIC", SQL_CURSOR_DYNAMIC, 
CONST_PERSISTENT | CONST_CS);
+#endif
REGISTER_LONG_CONSTANT("SQL_CURSOR_STATIC", SQL_CURSOR_STATIC, 
CONST_PERSISTENT | CONST_CS);

REGISTER_LONG_CONSTANT("SQL_KEYSET_SIZE", SQL_KEYSET_SIZE, CONST_PERSISTENT | 
CONST_CS);
@@ -758,7 +760,11 @@
/* Try to set CURSOR_TYPE to dynamic. Driver will replace this 
with other
   type if not possible.
*/
+#ifdef HAVE_IBMDB2
+   if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, 
+SQL_CURSOR_FORWARD_ONLY)
+#else
if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, 
SQL_CURSOR_DYNAMIC)
+#endif
== SQL_ERROR) {
odbc_sql_error(conn->henv, conn->hdbc, result->stmt, " 
SQLSetStmtOption"
);
SQLFreeStmt(result->stmt, SQL_DROP);
@@ -1085,7 +1091,11 @@
/* Try to set CURSOR_TYPE to dynamic. Driver will replace this 
with other
   type if not possible.
 */
+#ifdef HAVE_IBMDB2
+   if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, 
+SQL_CURSOR_FORWARD_ONLY)
+#else
 

[PHP-DEV] Bug #8591 Updated: Build fails at main/main.c because XtOffset got defined to something bogus.

[derick]

ID: 8591
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0.4
Assigned To: 
Comments:

No feedback

Previous Comments:
---

[2001-06-12 17:13:23] [EMAIL PROTECTED]

Could you please try the latest CVS snapshot from
http://snaps.php.net/ to see if this is fixed or not?

--Jani


---

[2001-05-23 13:53:24] [EMAIL PROTECTED]

Could you please try the latest CVS snapshot from 
http://snaps.php.net/ to see if this is fixed now.

--Jani


---

[2001-01-08 05:41:49] [EMAIL PROTECTED]

I believe the problem is that __arm is defined but LINUX is not, so main/php.h 
#defines XtOffset(p_type,field) to _Offsetof(p_type,field), and _Offsetof() is not 
defined on Linux, which causes lots of parse errors and a build failure. Simply 
commenting out the offending part of php.h allows the build to succeed, but this 
probably isn't the correct fix.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8591&edit=2


-- 
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 #9261 Updated: odbc to an oracle 'view' fails

[derick]

ID: 9261
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: ODBC related
Operating system: 
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

No feedback

Previous Comments:
---

[2001-06-08 15:54:11] [EMAIL PROTECTED]

from where did you remove the HAVE_SQL_EXTENDED_FETCH define?

---

[2001-02-14 19:37:10] [EMAIL PROTECTED]

Hi,

I disabled "#define HAVE_SQL_EXTENDED_FETCH 1 " and that seems to do the thing.

/Bengt

---

[2001-02-14 14:26:15] [EMAIL PROTECTED]

I've tried SQL_CUR_USE_ODBC, SQL_CUR_USE_IF_NEEDED, SQL_CUR_USE_DRIVER and 
SQL_CUR_DEFAULT with the same result.

/Bengt

---

[2001-02-14 10:19:50] [EMAIL PROTECTED]

You could try to pass SQL_CUR_USE_ODBC as additional
parameter to odbc_connect() and see if this helps.

---

[2001-02-14 09:54:19] [EMAIL PROTECTED]

Hi, 
I' running openlink to an oracle(8.1.5) server. When I try to do a 'select' from a 
view I get the error from PHP:

"Warning: SQL error: [OpenLink][ODBC][Driver]No key columns found for table referenced 
by keyset driven cursor., SQL state IM909 in SQLPrepare "

(Using the same driver from Perl works fine)



---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9261&edit=2


-- 
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] foreach behavior and error suppression (@foo)

[Stanislav Malyshev]

>> What looks better and is easier to read?:

For me - the first one. Go figure what that @ is about. Also, 'if' allows
you for 'else'.

>> it. But, making foreach threat NULL variables as empty arrays, would
>> be a goof thing IMO.

Maybe it is worth to demote this warning to E_NOTICE? I personally don't
have a strong opinion on this.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
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 #9775 Updated: libmcrypt-2.4.9 causes random segmentation faults

[derick]

ID: 9775
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproducible crash
Operating system: 
PHP Version: 4.0.4pl1
Assigned To: derick
Comments:

Please try the latest version of libmcrypt. If it still
cores, reopen this report.

Derick

Previous Comments:
---

[2001-06-10 21:32:11] [EMAIL PROTECTED]

I think derick fixed this one.. can you try latest CVS please.

- James

---

[2001-05-01 03:27:56] [EMAIL PROTECTED]

I can reproduce this on my own system, both thtough PHP and with a C-program. As the 
author of libmcrypt cannot reproduce this, I'll suspend this bug until I know more 
about it.

---

[2001-04-16 07:10:58] [EMAIL PROTECTED]

I committed the fix for the memleak, but the crash is most likely a problem in 
libmcrypt, because I had those some things when running a C program which uses these 
functions. The author of libmcrypt says this can be a problem in different versions of 
libltdl, but I had the same problem with both the 1.2 and 2.0 versions. I'm awaiting 
further response from Nikos now.

---

[2001-04-16 05:30:50] [EMAIL PROTECTED]

Derick Ill assign this one to you so you remember it.. you said you had a fix.

- James

---

[2001-03-16 09:36:27] [EMAIL PROTECTED]

These memleaks where indeed caused by not freeing the key. Fix is pending until I have 
access to CVS again.

---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9775&edit=2


-- 
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] Bug #11796 Updated: get_meta_tags doesn't work whenthe title tag consists of single quote

[Chu Lim]

Hi Derick,

Sorry that I have missed sending out the email twice.
I just upgraded the php to 4.0.6, and I tried to use the get_meta_tag,
but the problem still exists.
Can you enlighten me where can the problem be?
Thanks.


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 4:05 PM
Subject: Re: [PHP-DEV] Bug #11796 Updated: get_meta_tags doesn't work
whenthe title tag consists of single quote


> Hello,
>
> yes, this is fixed as Sean already told you in an earlier update to this
> bugreport.
>
> Derick
>
> On 3 Jul 2001 [EMAIL PROTECTED] wrote:
>
> > ID: 11796
> > User Update by: [EMAIL PROTECTED]
> > Status: Closed
> > Bug Type: Unknown/Other Function
> > Operating system: Linux
> > PHP Version: 4.0.5
> > Description: get_meta_tags doesn't work when the title tag consists of
single quote
> >
> > Hi, have another question.
> > Is this bug fixed in 4.0.6?
> > If so, I would rather upgrade my php to 4.0.6.
> >
> > Thanks.
> >
> >
> >
> >
> > Previous Comments:
>
> --
-
> >
> > [2001-07-03 03:03:40] [EMAIL PROTECTED]
> >
> > nm, wrong entry
> >
>
> --
-
> >
> > [2001-07-03 03:01:34] [EMAIL PROTECTED]
> >
> > >From the ChangeLog:
> >
> > 2001-03-06  Sean Bright  <[EMAIL PROTECTED]>
> >
> > * ext/standard/file.c: Typo.
> >
> > * ext/standard/file.c:
> > get_meta_tags now allows attributes that are not quoted as well as
those
> > that are.  It follows the HTML 4.01 specification for attribute
values
> > outlined here ->
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
> >
> > You could have checked this yourself BTW.
> >
> > Derick
> >
>
> --
-
> >
> > [2001-07-03 02:12:28] [EMAIL PROTECTED]
> >
> > Hi, have another question.
> > Is this bug fixed in 4.0.6?
> > If so, I would rather upgrade my php to 4.0.6.
> >
> > Thanks.
> >
> >
> >
> >
>
> --
-
> >
> > [2001-07-02 04:12:45] [EMAIL PROTECTED]
> >
> > Either grab a snapshot form snaps.php.net or follow the instructions on
getting the CVS version on: www.php.net/anoncvs.php
> >
> > Derick
> >
>
> --
-
> >
> > [2001-07-02 04:11:02] [EMAIL PROTECTED]
> >
> > http://www.php.net/anoncvs.php
> >
> >
>
> --
-
> >
> > The remainder of the comments for this report are too long.
> > To view the rest of the comments, please
> > view the bug report online.
> >
> > Full Bug description available at: http://bugs.php.net/?id=11796
> >
> >
> > --
> > 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]
> >
>
> Derick Rethans
>
> -
> PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>  SRM: Site Resource Manager - www.vl-srm.net
> -
>


-- 
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 #8591 Updated: Build fails at main/main.c because XtOffset got defined to something bogus.

[alex]

ID: 8591
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Compile Failure
Operating system: ARM/Linux (Titan VI)
PHP Version: snapshot 4-200106111635
Description: Build fails at main/main.c because XtOffset got defined to something 
bogus.

I just tried it with what appears to be the latest snapshot available at snaps.php.net 
(4-200106111635)- 6th of July? It still has the bug, my original description applies 
exactly. Sorry for not replying earlier but I didn't have access to the machine at the 
time, then I forgot about it until you sent the reminder just now.

Previous Comments:
---

[2001-07-03 04:51:48] [EMAIL PROTECTED]

No feedback

---

[2001-06-12 17:13:23] [EMAIL PROTECTED]

Could you please try the latest CVS snapshot from
http://snaps.php.net/ to see if this is fixed or not?

--Jani


---

[2001-05-23 13:53:24] [EMAIL PROTECTED]

Could you please try the latest CVS snapshot from 
http://snaps.php.net/ to see if this is fixed now.

--Jani


---

[2001-01-08 05:41:49] [EMAIL PROTECTED]

I believe the problem is that __arm is defined but LINUX is not, so main/php.h 
#defines XtOffset(p_type,field) to _Offsetof(p_type,field), and _Offsetof() is not 
defined on Linux, which causes lots of parse errors and a build failure. Simply 
commenting out the offending part of php.h allows the build to succeed, but this 
probably isn't the correct fix.

---


Full Bug description available at: http://bugs.php.net/?id=8591


-- 
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 #11852: Session ID not transferred correctly within framesets

[comp]

From: [EMAIL PROTECTED]
Operating system: Win98SE
PHP version:  4.0.6
PHP Bug Type: *Session related
Bug description:  Session ID not transferred correctly within framesets

starting indexfile:

session_start()
session_register("var")

in the header of the frameset definition (index) file, even transferring the  
directly to the contained frame (control) can't convince the control-file to take on 
the same session id as the indexfile has submitted to it. 


starting controlfile:

session_start()

tried everything. all worked perfect on the 4.0.5 release! i can't find any scripting 
bug...


-- 
Edit Bug report at: http://bugs.php.net/?id=11852&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 #11853: unknown option -l-l

[php]

From: [EMAIL PROTECTED]
Operating system: Suse Linux 7.0
PHP version:  4.0.6
PHP Bug Type: *Install and Config
Bug description:  unknown option -l-l

make-script  compiled all sub-dirs and changes to php-4.0.6. but nothing could be 
compiled - output: /usr/bin/ld: cannot find -l-l

this is documented in debug.log too:

LIBS: -l -l -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv

gcc -o conftest -g -O2 -DEAPI_MM -DLINUX2 -DMOD-SSL=206105 -DUSEHSREGEX -DEAPI 
-DUSE_EXPAT -DSUPPORT_UTF8 conftest.c $LIBS
and the error-message from above

I tried to delete -l -l -l in configure.vars.mk, but it did'nt help.
Perhaps you have an idea.
Thanx


-- 
Edit Bug report at: http://bugs.php.net/?id=11853&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 #11853 Updated: unknown option -l-l

[derick]

ID: 11853
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Install and Config
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

What is your configure line?

Derick

Previous Comments:
---

[2001-07-03 05:53:58] [EMAIL PROTECTED]

make-script  compiled all sub-dirs and changes to php-4.0.6. but nothing could be 
compiled - output: /usr/bin/ld: cannot find -l-l

this is documented in debug.log too:

LIBS: -l -l -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv

gcc -o conftest -g -O2 -DEAPI_MM -DLINUX2 -DMOD-SSL=206105 -DUSEHSREGEX -DEAPI 
-DUSE_EXPAT -DSUPPORT_UTF8 conftest.c $LIBS
and the error-message from above

I tried to delete -l -l -l in configure.vars.mk, but it did'nt help.
Perhaps you have an idea.
Thanx

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11853&edit=2


-- 
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] Bug #11796 Updated: get_meta_tags doesn't work whenthe title tag consists of single quote

[Sean R. Bright]

Chu:

The bug is not fixed in 4.0.6.  4.0.6 was released before the bug was fixed.
It will, however, be in 4.0.7 when it is released.  In the meantime you can
get a development snapshot from http://snaps.php.net/ which contains the
changes that were made.

Thanks,
Sean

> -Original Message-
> From: Chu Lim [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 03, 2001 5:07 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Bug #11796 Updated: get_meta_tags doesn't work
> whenthe title tag consists of single quote
>
>
> Hi Derick,
>
> Sorry that I have missed sending out the email twice.
> I just upgraded the php to 4.0.6, and I tried to use the get_meta_tag,
> but the problem still exists.
> Can you enlighten me where can the problem be?
> Thanks.
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 03, 2001 4:05 PM
> Subject: Re: [PHP-DEV] Bug #11796 Updated: get_meta_tags doesn't work
> whenthe title tag consists of single quote
>
>
> > Hello,
> >
> > yes, this is fixed as Sean already told you in an earlier
> update to this
> > bugreport.
> >
> > Derick
> >
> > On 3 Jul 2001 [EMAIL PROTECTED] wrote:
> >
> > > ID: 11796
> > > User Update by: [EMAIL PROTECTED]
> > > Status: Closed
> > > Bug Type: Unknown/Other Function
> > > Operating system: Linux
> > > PHP Version: 4.0.5
> > > Description: get_meta_tags doesn't work when the title
> tag consists of
> single quote
> > >
> > > Hi, have another question.
> > > Is this bug fixed in 4.0.6?
> > > If so, I would rather upgrade my php to 4.0.6.
> > >
> > > Thanks.
> > >
> > >
> > >
> > >
> > > Previous Comments:
> >
> >
> --
> 
> -
> > >
> > > [2001-07-03 03:03:40] [EMAIL PROTECTED]
> > >
> > > nm, wrong entry
> > >
> >
> >
> --
> 
> -
> > >
> > > [2001-07-03 03:01:34] [EMAIL PROTECTED]
> > >
> > > >From the ChangeLog:
> > >
> > > 2001-03-06  Sean Bright  <[EMAIL PROTECTED]>
> > >
> > > * ext/standard/file.c: Typo.
> > >
> > > * ext/standard/file.c:
> > > get_meta_tags now allows attributes that are not
> quoted as well as
> those
> > > that are.  It follows the HTML 4.01 specification for
> attribute
> values
> > > outlined here ->
> http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
> > >
> > > You could have checked this yourself BTW.
> > >
> > > Derick
> > >
> >
> >
> --
> 
> -
> > >
> > > [2001-07-03 02:12:28] [EMAIL PROTECTED]
> > >
> > > Hi, have another question.
> > > Is this bug fixed in 4.0.6?
> > > If so, I would rather upgrade my php to 4.0.6.
> > >
> > > Thanks.
> > >
> > >
> > >
> > >
> >
> >
> --
> 
> -
> > >
> > > [2001-07-02 04:12:45] [EMAIL PROTECTED]
> > >
> > > Either grab a snapshot form snaps.php.net or follow the
> instructions on
> getting the CVS version on: www.php.net/anoncvs.php
> > >
> > > Derick
> > >
> >
> >
> --
> 
> -
> > >
> > > [2001-07-02 04:11:02] [EMAIL PROTECTED]
> > >
> > > http://www.php.net/anoncvs.php
> > >
> > >
> >
> >
> --
> 
> -
> > >
> > > The remainder of the comments for this report are too long.
> > > To view the rest of the comments, please
> > > view the bug report online.
> > >
> > > Full Bug description available at: http://bugs.php.net/?id=11796
> > >
> > >
> > > --
> > > 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]
> > >
> >
> > Derick Rethans
> >
> >
> -
> > PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
> >  SRM: Site Resource Manager - www.vl-srm.net
> >
> -
> >
>
>
> --
> 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 #11854: PHP caused a stack fault in module PHP4TS.DLL at 0177:100a13c6.

[toxic_]

From: [EMAIL PROTECTED]
Operating system: Windows 98 (Not SE)
PHP version:  4.0.5
PHP Bug Type: Reproducible crash
Bug description:  PHP caused a stack fault in module PHP4TS.DLL at 0177:100a13c6.

PHP caused a stack fault in module PHP4TS.DLL at 0177:100a13c6.

Was coding a Mail script - Was trying to call the same function within a function (to 
draw it out as what to do with the vars on the page). 
Overview: Variables Coming in -> Mail the Data || No Variables -> Draw the form

Running PHPTriad 2.11 -> PHP 4.0.5 & Apache(win32) 1.3.14

";
echo "Email: ";
echo "";
echo "";
}
}
?>











-- 
Edit Bug report at: http://bugs.php.net/?id=11854&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 #11854 Updated: PHP caused a stack fault in module PHP4TS.DLL at 0177:100a13c6.

[derick]

ID: 11854
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproducible crash
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

There is no way to prevent PHP from doing this. Infinite recursion is not supported, 
and the performance hit to check for this would be too high, and there is a possbility 
that this doesn't work even.

Derick

Previous Comments:
---

[2001-07-03 07:39:33] [EMAIL PROTECTED]

PHP caused a stack fault in module PHP4TS.DLL at 0177:100a13c6.

Was coding a Mail script - Was trying to call the same function within a function (to 
draw it out as what to do with the vars on the page). 
Overview: Variables Coming in -> Mail the Data || No Variables -> Draw the form

Running PHPTriad 2.11 -> PHP 4.0.5 & Apache(win32) 1.3.14

";
echo "Email: ";
echo "";
echo "";
}
}
?>










---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11854&edit=2


-- 
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] Bug #11780: udm_find makes php crash

[Sergey Kartashoff]

On 28 Jun 2001 [EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: Linux
> PHP version:  4.0.6
> PHP Bug Type: Unknown/Other Function
> Bug description:  udm_find makes php crash
>
> Important notice: It seems to crash ONLY when the word
> belongs the dictionary (dict table).
> (This seems to prove that the udm_agent is well-defined)

Try to recompile mnogosearch without threads, then recompile php.
Please give me feedback if it helps.
Thank you.


-- 
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] ChangeLog

[Andrei Zmievski]

On Tue, 03 Jul 2001, Derick Rethans wrote:
> Hello,
> 
> I just noticed that the ChangeLog does not get updated. The last entry is:
> 2001-05-23  Sascha Schumann  <[EMAIL PROTECTED]>
> 
> And that's more than a month ago.

Yes, that's due to the mailing list/CVS machine being offline. I'm going
to try and put up lxr/bonsai and the changelog processing this week.

-Andrei

For society, it's probably a good thing that engineers value function over
appearance.  For example, you wouldn't want engineers to build nuclear power
plants that only _look_ like they would keep all the radiation inside.
(Scott Adams - The Dilbert principle)

-- 
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] switch, equality and preg_match

[Brian Moon]

If you look back to the original problem, switch was matching the 0 returned
from preg_match to a string.  However, if the return value is a boolean it
would not match 0 to a string.  However, I guess it would then match the
true to a string.

Brian Moon
--
dealnews.com, Inc.
Makers of dealnews & dealmac
http://dealnews.com/ | http://dealmac.com/


- Original Message -
From: "Jon Parise" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>
Cc: "Andrei Zmievski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, July 02, 2001 7:21 PM
Subject: Re: [PHP-DEV] switch, equality and preg_match


> On Mon, Jul 02, 2001 at 05:01:43PM -0500, Brian Moon wrote:
>
> > IMO, I like preg_match to return a bool and preg_match_all return a
count.
> > But that is me.  It may be thought of as inconsistent to some.  I just
see
> > the functions has having a different purpose.
>
> That would make sense.  preg_match_all() would return 1 if only
> one match is found, so there's no need for preg_match() to return
> the number of matches.
>
> However, even if preg_match() were to return a one or zero, it
> would still function the same in boolean evaluations.  That makes
> the whole thing simply a matter of "correctness".  Returning an
> 'int' would be more consistent but returning a boolean would be
> specific.
>
> --
> Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
> 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]

[PHP-DEV] Access 2000 Bug - Insert and Update statement does not work (no write access at all)

[Sebastian Pötschke]

Hi Folks,

we did implement a GPS Reference Station Webserver using Apache, PHP and
ODBC Connectivity to MS Access Database files (found at
http://www.virtualrtk.com). Currently we are using Apache 1.3.20, PHP 4.0.6
and the
latest Version of  Microsoft Access mdb-Driver 4.00.5303.1 got from
Office2000
Service Pack 2. And now since we using Access 2000 in the back we got
serious problems regarding the database connectivity. In other words we are
not able to write any data to the tables using PHP as we did before
through Access 97 Driver (fetching tables still works fine). I'm pretty sure
that this problem is related to Access 2000 because I switched back to
Access 97 and it worked just fine. Does anyone know if the is any
difference between Access 2000 and 97?

Regards
Sebastian

Sebastian Poetschke - Trimble Terrasat GmbH
Software Development Engineer
Haringstrasse 19 - 85635 Hoehenkirchen - Germany
Tel.: +49 (0) 8102 7433-0 - Fax: +49 (0) 8102 7433-131
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] Insert queries add TWO records to database

[John (*\\*)]

Tried to send this but got the following message from your server:

Warning: Could not execute mail delivery program in
/local/Web/sites/phpweb/bugs.php on line 411


Mail not sent!
Please send this page in a mail to [EMAIL PROTECTED] manually.

So I have:

From: [EMAIL PROTECTED]
Operating system: WinNT4
PHP version:  4.0.6
PHP Bug Type: MySQL related
Bug description:  Insert queries add TWO records to database

All my insert queries seem to add two records to the database instead of
one.

I was using MS Access 2000 and did not have the problem. I am now using
MySQL and all insert queries add 2 recs?!

Eg.

$sql = "INSERT INTO Campaign
(CampaignName,CampaignDesc,StartDate,EndDate,CompanyId,CampaignStatus,Admini
stratorId) VALUES
('$name','$desc','$start_date','$end_date',$company_id,0,1)";

$res_insert_campaign=mysql_query($sql,$conn);

if (!$res_insert_campaign) {
  return false;
}

With the
result:

CampaignId  CompanyId   AdministratorId CampaignNameCampaignDes 
StartDate
EndDate ProposalPDF InvoicePDF  CampaignStatus

11  45  1   Test Alltesting 2001-07-03  2003-07-03  NULL   
 NULL0
12  45  1   Test Alltesting 2001-07-03  2003-07-03  NULL   
 NULL0

(2 row(s) affected)

A guy in the US seems to be having the same problem with Sybase.  His
details are:

Rob Donat
Sedonatech, Inc.
1735 W. Diversey Suite 521
Chicago, IL 60614
[EMAIL PROTECTED]
312-501-1200 cell
773-388-0271(2) office(fax)

Do u know if this is a PHP, MySQL, ODBC or server setting bug?

My fix at the moment is to insert a record, select it and delete one if
2 are added.

This is very messy and I would like to know if I have to go back to
Access or start using another relational database?

Does anyone else have this problem or, preferebly, how do I fix it?

Thank you for any help.

mailto:[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] PSPELL with PHP

[Lindsey Simon]

I've just compiled and installed php-4.0.6 --with-pspell support. However,
the pspell_new function gives me the following error:

Warning: PSPELL couldn't open the dictionary. reason: I'm sorry I can't find any
suitable word lists for the language-tag "en".

the line causing the error reads:
$pspell_config = pspell_config_create ("en","american");
$pspell_link = pspell_new_config($pspell_config);


I've created a file en-american.pwli in the pkgdata directory which points absolutely
to a wordlist american-words.95.  

I've been unable to find much clear documentation about the setup procedure for pspell
with php and I suspect I'm missing something simple. Does anyone have a suggestion
that may help?

-lindsey



-- 
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 #7252 Updated: Intermittent Segfault when running sybase_connect or sybase_pconnect

[isamuel]

ID: 7252
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Sybase (dblib) related
Operating system: Redhat 6.2 - Kernel 2.2.17
PHP Version: 4.0.3pl1
Description: Intermittent Segfault when running sybase_connect or sybase_pconnect

I ended up using the Sybase ct-libraries when compiling PHP and didn't have this 
problem anymore.

I don't have access to try with a newer version of PHP now.

i.


Previous Comments:
---

[2001-07-03 04:49:31] [EMAIL PROTECTED]

Can you confirm this is still a problem with PHP 4.0.6?

Derick

---

[2001-06-12 17:39:10] [EMAIL PROTECTED]

Please try PHP 4.0.6RC3 from http://www.php.net/~andi/php-4.0.6RC3.tar.gz
and condigure it using also --enable-debug to get 
useful backtrace.

--Jani


---

[2000-10-16 12:43:26] [EMAIL PROTECTED]

gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x4006036c in dbsetlname () from /usr/local/sybase-11.9.2/lib/libsybdb.so
(gdb) bt
#0  0x4006036c in dbsetlname () from /usr/local/sybase-11.9.2/lib/libsybdb.so
#1  0x80f7080 in php_rshutdown_sybase ()
#2  0x80f747e in php_if_sybase_connect ()
#3  0x812f21c in execute ()
#4  0x810bdf8 in zend_execute_scripts ()
#5  0x80aa091 in php_execute_script ()
#6  0x81158d9 in apache_php_module_main ()
#7  0x80a7d3b in send_php ()
#8  0x80a7d68 in send_parsed_php ()
#9  0x81392f3 in ap_invoke_handler ()
#10 0x814cc99 in ap_some_auth_required ()
#11 0x814ccfc in ap_process_request ()
#12 0x814450e in ap_child_terminate ()
#13 0x81446bc in ap_child_terminate ()
#14 0x8144819 in ap_child_terminate ()
#15 0x8144e46 in ap_child_terminate ()
#16 0x81455e3 in main ()
#17 0x401579cb in __libc_start_main (main=0x814528c , argc=4,
argv=0xbb34, init=0x8078c9c <_init>, fini=0x81e511c <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbb2c)
at ../sysdeps/generic/libc-start.c:92

Apache 1.3.12 with mod_ssl 2.2.6 and OpenSSL 2.6.6
PHP configure:
./configure --with-apache=../apache_1.3.12 --with-sybase=/usr/local/sybase-11.9.2 
--enable-track-vars

Apache configure:
./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a 
--enable-module=ssl


---


Full Bug description available at: http://bugs.php.net/?id=7252


-- 
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] Bug #11780: udm_find makes php crash

[Cedric ANES]

 Hi Sergey !

Thanks a lot for your input.
It was actually already compiled that way.
However, you gave me an idea..
I've specified the path of the mysql binaries
( --with-mysql=/usr/local/mysql ) [for mnoGoSearch compil]
and now it seems to work fine !

The funny thing is that when I use only  --with-mysql, all the command line
tools
like the indexer are working fine and updates the databases accordingly !

Shall I update bug #11780 ?

Thanks again !

Best regards,

  Cedric

- Original Message -
From: "Sergey Kartashoff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 3:13 PM
Subject: Re: [PHP-DEV] Bug #11780: udm_find makes php crash


> On 28 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > From: [EMAIL PROTECTED]
> > Operating system: Linux
> > PHP version:  4.0.6
> > PHP Bug Type: Unknown/Other Function
> > Bug description:  udm_find makes php crash
> >
> > Important notice: It seems to crash ONLY when the word
> > belongs the dictionary (dict table).
> > (This seems to prove that the udm_agent is well-defined)
>
> Try to recompile mnogosearch without threads, then recompile php.
> Please give me feedback if it helps.
> Thank you.


-- 
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] PSPELL with PHP

[Vlad Krupin]

quite likely you missed something simple. Can you do the following?
1. go into pspell/example directory
2. do 'make example-c
3. do 'su nobody'
4. run './example-c en' (or whichever language you use)
5. try to spellcheck a word, e.g. 's helllo'
And see what happens. If this does not succeed, you probably did not 
install pspell or aspell correctly. Otherwise we'll have to do some more 
problem hunting.

I never really tried to do anything more than just a basic install of 
the spellchecker (e.g. different dictionaries, languages, etc.), so I 
might be able to help you a bit if it is not installed correctly, but 
not much.

Vlad



Lindsey Simon wrote:

>I've just compiled and installed php-4.0.6 --with-pspell support. However,
>the pspell_new function gives me the following error:
>
>Warning: PSPELL couldn't open the dictionary. reason: I'm sorry I can't find any
>suitable word lists for the language-tag "en".
>
>the line causing the error reads:
>$pspell_config = pspell_config_create ("en","american");
>$pspell_link = pspell_new_config($pspell_config);
>
>
>I've created a file en-american.pwli in the pkgdata directory which points absolutely
>to a wordlist american-words.95.  
>
>I've been unable to find much clear documentation about the setup procedure for pspell
>with php and I suspect I'm missing something simple. Does anyone have a suggestion
>that may help?
>
>-lindsey
>
>
>




-- 
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 #11861: Can't set any session variable

[M . Izydorski]

From: [EMAIL PROTECTED]
Operating system: Win 2k
PHP version:  4.0.6
PHP Bug Type: *Session related
Bug description:  Can't set any session variable

The problem is, that I can't set any session variables when I turn register_globals 
Off. I read documentation carefully, but following code doesn't work - variable "user" 
isn't set in main.php. I'm not so sure what's mean of:

PHP DOC> only members of the global associative array
PHP DOC> $HTTP_SESSION_VARS can be registered as session
PHP DOC> variables.The restored session variables will only PHP DOC> be available in 
the array $HTTP_SESSION_VARS

After execute following code, $HTTP_SESSION_VARS["user"] isn't set in
main.php.


> $user = $s_user;
> $HTTP_SESSION_VARS["user"] = $s_user;
> session_register("user");
> header("Location: main.php");
> exit;


-- 
Edit Bug report at: http://bugs.php.net/?id=11861&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] Access 2000 Bug - Insert and Update statement does not work (no write access at all)

[Andi Gutmans]

Hi,

I can't help you too much but I am pretty sure I bumped into problems after 
installing Access 2000 w/ an app which uses Access. I think the ODBC driver 
was changed in 2000.
Maybe you can find something at msdn.microsoft.com. If you find anything 
useful please let me know.

Andi

At 05:25 PM 7/3/2001 +0200, Sebastian Pötschke wrote:
>Hi Folks,
>
>we did implement a GPS Reference Station Webserver using Apache, PHP and
>ODBC Connectivity to MS Access Database files (found at
>http://www.virtualrtk.com). Currently we are using Apache 1.3.20, PHP 4.0.6
>and the
>latest Version of  Microsoft Access mdb-Driver 4.00.5303.1 got from
>Office2000
>Service Pack 2. And now since we using Access 2000 in the back we got
>serious problems regarding the database connectivity. In other words we are
>not able to write any data to the tables using PHP as we did before
>through Access 97 Driver (fetching tables still works fine). I'm pretty sure
>that this problem is related to Access 2000 because I switched back to
>Access 97 and it worked just fine. Does anyone know if the is any
>difference between Access 2000 and 97?
>
>Regards
>Sebastian
>
>Sebastian Poetschke - Trimble Terrasat GmbH
>Software Development Engineer
>Haringstrasse 19 - 85635 Hoehenkirchen - Germany
>Tel.: +49 (0) 8102 7433-0 - Fax: +49 (0) 8102 7433-131
>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 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 #8346 Updated: DB2 CLI do not support SQL_CURSOR_DYNAMIC

[sniper]

ID: 8346
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Suspended
Status: Closed
Bug Type: ODBC related
Operating system: 
PHP Version: 4.0.3pl1
Assigned To: 
Comments:



Previous Comments:
---

[2001-06-11 10:14:15] [EMAIL PROTECTED]

this patch is a really bad idea.  

hopefully i'll have a better solution for you in the near future... i'm awaiting patch 
confirmation from some others before commiting it.

---

[2000-12-21 03:09:55] [EMAIL PROTECTED]

The change above have effect of disabling scrolling through lists. However retriving 
one record is not a problem.

Here's the script which demonstrates the bug:



Output as follows:

test.php(9) : Warning - SQL error: [IBM][CLI Driver][DB2/6000] SQL0954C  Not enough 
storage is available in the application h
eap to process the statement.  SQLSTATE=57011
, SQL state 57011 in SQLExecDirect
test.php(11) : Warning - Supplied argument is not a valid ODBC result resource
test.php(15) : Warning - Supplied argument is not a valid ODBC result resource


---

[2000-12-21 01:48:35] [EMAIL PROTECTED]

When you execute a php script which uses odbc_exec for more than 946 times (milage may 
vary), the following error message is returned:

Warning - SQL error: [IBM][CLI Driver][DB2/6000] SQL0954C  Not enough storage is 
available in the application heap to process the statement.  SQLSTATE=57011

The following information is discovered in IBM DB2 CLI manual:

SQL_ATTR_CURSOR_TYPE (DB2 CLI v2) 
A 32-bit integer value that specifies the cursor type. The supported values are: 

SQL_CURSOR_FORWARD_ONLY = The cursor only scrolls forward. 
SQL_CURSOR_STATIC = The data in the result set is static. This is the default. 
SQL_CURSOR_KEYSET_DRIVEN = DB2 CLI supports a pure keyset cursor. The SQL_KEYSET_SIZE 
statement attribute is ignored. To limit the size of the keyset the application must 
limit the size of the result set by setting the SQL_ATTR_MAX_ROWS attribute to a value 
other than 0. 
This option cannot be specified for an open cursor. 

If the specified cursor type is not supported by the data source, CLI substitutes a 
different cursor type and returns SQLSTATE 01S02 (Option value changed). For a mixed 
or dynamic cursor, CLI substitutes, in order, a keyset-driven or static cursor. 

Note: The following value has also been defined by ODBC, but is not supported by DB2 
CLI: 
SQL_CURSOR_DYNAMIC 
If this values is used, DB2 CLI sets the statement attribute to SQL_CURSOR_STATIC 
SQL_CURSOR_FORWARD_ONLY and returns SQLSTATE 01S02 (Option value changed). In this 
case the application should call SQLGetStmtAttr() to query the actual value. 
 
The quick work around is to edit ext/odbc/php_odbc.c, and disable SQL_CURSOR_DYNAMIC, 
and to change all instances of SQL_CURSOR_DYNAMIC to SQL_CURSOR_FORWARD_ONLY.  It 
appear that DB2/CLI exhibits memory leak when statement type is set to 
SQL_CURSOR_DYNAMIC.

The diff follows:

--- php_odbc.c.orig Thu Dec 21 00:44:49 2000
+++ php_odbc.c  Thu Dec 21 01:00:30 2000
@@ -354,7 +354,9 @@
REGISTER_LONG_CONSTANT("SQL_CURSOR_TYPE", SQL_CURSOR_TYPE, CONST_PERSISTENT | 
CONST_CS);
REGISTER_LONG_CONSTANT("SQL_CURSOR_FORWARD_ONLY", SQL_CURSOR_FORWARD_ONLY, 
CONST_PERSISTENT | CO
NST_CS);
REGISTER_LONG_CONSTANT("SQL_CURSOR_KEYSET_DRIVEN", SQL_CURSOR_KEYSET_DRIVEN, 
CONST_PERSISTENT | 
CONST_CS);
+#ifndef HAVE_IBMDB2
REGISTER_LONG_CONSTANT("SQL_CURSOR_DYNAMIC", SQL_CURSOR_DYNAMIC, 
CONST_PERSISTENT | CONST_CS);
+#endif
REGISTER_LONG_CONSTANT("SQL_CURSOR_STATIC", SQL_CURSOR_STATIC, 
CONST_PERSISTENT | CONST_CS);

REGISTER_LONG_CONSTANT("SQL_KEYSET_SIZE", SQL_KEYSET_SIZE, CONST_PERSISTENT | 
CONST_CS);
@@ -758,7 +760,11 @@
/* Try to set CURSOR_TYPE to dynamic. Driver will replace this 
with other
   type if not possible.
*/
+#ifdef HAVE_IBMDB2
+   if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, 
+SQL_CURSOR_FORWARD_ONLY)
+#else
if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, 
SQL_CURSOR_DYNAMIC)
+#endif
== SQL_ERROR) {
odbc_sql_error(conn->henv, conn->hdbc, result->stmt, " 
SQLSetStmtOption"
);
SQLFreeStmt(result->stmt, SQL_DROP);
@@ -1085,7 +1091,11 @@
/* Try to set CURSOR_TYPE to dynamic. Driver will replace this 
with other
   type if not possible.
 */
+#ifdef HAVE_IBMDB2
+   if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, 
+SQL_CURSOR_FORWARD_ONLY)
+#else
if

[PHP-DEV] Bug #9793 Updated: ldap_mod_add with bad params cause Segfault

[sniper]

ID: 9793
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Analyzed
Bug Type: LDAP related
Operating system: 
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

I made a little mistake. This can be reproduced when ldap extension is compiled as 
shared extension.

--Jani



Previous Comments:
---

[2001-07-03 04:53:29] [EMAIL PROTECTED]

No feedback

---

[2001-06-04 00:13:33] [EMAIL PROTECTED]

Please try the latest release candidate from:

http://www.php.net/~andi/php-4.0.6RC2.tar.gz

Also, try generating a GDB backtrace if it still crashes.
(I'm still unable to reproduce this..)

--Jani


---

[2001-03-19 03:33:21] [EMAIL PROTECTED]

Bug Database <[EMAIL PROTECTED]> writes:

> I can't reproduce this. Which ldap library are you using?
> OpenLdap? And version? I tried with openldap 2.0.7 and
> it just gave an error on that first example.

I should have been more descriptive.
libraries are openldap 2.0.7.

Complete script is here and it's strace is attached:
  Array("1" => "[EMAIL PROTECTED]")));
 ldap_close($_ldap);
 ?>

Output was:
 ondrej@druid:~$ php4 ldap.php 
 Segmentation fault


---

[2001-03-16 13:50:16] [EMAIL PROTECTED]

I can't reproduce this. Which ldap library are you using?
OpenLdap? And version? I tried with openldap 2.0.7 and
it just gave an error on that first example.


--Jani


---

[2001-03-16 11:48:02] [EMAIL PROTECTED]

This cause SegFault:
ldap_mod_add($param, $dn, Array("mail" => Array("1" =>
"[EMAIL PROTECTED]")));


This one works ok:
ldap_mod_add($param, $dn, Array("mail" => Array("0" =>
"[EMAIL PROTECTED]")));


---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9793&edit=2


-- 
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 #11780 Updated: udm_find makes php crash

[sniper]

ID: 11780
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Unknown/Other Function
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

User feedback:


 Hi Sergey !

Thanks a lot for your input.
It was actually already compiled that way.
However, you gave me an idea..
I've specified the path of the mysql binaries
( --with-mysql=/usr/local/mysql ) [for mnoGoSearch compil]
and now it seems to work fine !

The funny thing is that when I use only  --with-mysql, all the command line
tools
like the indexer are working fine and updates the databases accordingly !



I guess you used this on PHP configure too?
It's better to use the external MySQL libraries if there
are some other Apache DSO's or some library that also uses 
Mysql.

--Jani
 

Previous Comments:
---

[2001-06-29 02:07:12] [EMAIL PROTECTED]

Just got a new backtrace with httpd -X:

Program received signal SIGSEGV, Segmentation fault.
__libc_free (mem=0x1) at malloc.c:2914
malloc.c:2914: No such file or directory.
(gdb) bt
#0  __libc_free (mem=0x1) at malloc.c:2914
#1  0x403a0bf1 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#2  0x4039cb26 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#3  0x40415bfe in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#4  0x40415d6f in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#5  0x4042aa41 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#6  0x40393bdb in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#7  0x4037a2ae in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#8  0x40379137 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#9  0x4037a088 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#10 0x40395dd0 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#11 0x40366dbc in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#12 0x40375bc7 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#13 0x40386ce4 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#14 0x403838bf in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#15 0x40384218 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#16 0x40384248 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#17 0x806ba5f in ap_invoke_handler ()
#18 0x807f375 in process_request_internal ()
#19 0x807f3d4 in ap_process_request ()
#20 0x8076871 in child_main ()
#21 0x80769fc in make_child ()
#22 0x8076b57 in startup_children ()
#23 0x8077154 in standalone_main ()
#24 0x80779b3 in main ()


---

[2001-06-29 01:32:31] [EMAIL PROTECTED]

BTW, if it can help, I'm using mnoGoSearch 3.1.16
and MySQL 3.23.35

---

[2001-06-28 10:05:25] [EMAIL PROTECTED]

To reproduce the problem :


Hello World
";
else
echo "Agent OK";
$res = udm_find( $udm_agent, "word" );
?>


Important notice: It seems to crash ONLY when the word
belongs the dictionary (dict table).
(This seems to prove that the udm_agent is well-defined)

Configuration :
./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --enable-trans-sid 
--with-curl --with-mnogosearch=/usr/local/bin/mnogosearch --enable-debug

Apache 1.3.19

Backtrace:

#0  _dl_lookup_versioned_symbol (undef_name=0x804bf7a "unlink", ref=0xbd18, 
symbol_scope=0x0, 
reference_name=0x40010187 "", version=0x40151048, reloc_type=7) at do-lookup.h:82
#1  0x40009cfa in fixup (l=0x40013368, reloc_offset=1668) at dl-runtime.c:75
#2  0x40009e70 in _dl_runtime_resolve () at dl-runtime.c:170
#3  0x80779b3 in main ()

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11780&edit=2


-- 
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] snapshots are not created.

[Jani Taskinen]

I doubt your change is in any of those snapshots..
Last one of them was created on 11th of June.

--clip--
-r--   1   3274130  Jun 11 16:36  php4-200106111635.tar.gz
--clip--


--Jani


On Tue, 3 Jul 2001, Sean R. Bright wrote:

>Chu:
>
>The bug is not fixed in 4.0.6.  4.0.6 was released before the bug was fixed.
>It will, however, be in 4.0.7 when it is released.  In the meantime you can
>get a development snapshot from http://snaps.php.net/ which contains the
>changes that were made.
>
>Thanks,
>Sean
>
>> -Original Message-
>> From: Chu Lim [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, July 03, 2001 5:07 AM
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: [PHP-DEV] Bug #11796 Updated: get_meta_tags doesn't work
>> whenthe title tag consists of single quote
>>
>>
>> Hi Derick,
>>
>> Sorry that I have missed sending out the email twice.
>> I just upgraded the php to 4.0.6, and I tried to use the get_meta_tag,
>> but the problem still exists.
>> Can you enlighten me where can the problem be?
>> Thanks.
>>
>>
>> - Original Message -
>> From: <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Tuesday, July 03, 2001 4:05 PM
>> Subject: Re: [PHP-DEV] Bug #11796 Updated: get_meta_tags doesn't work
>> whenthe title tag consists of single quote
>>
>>
>> > Hello,
>> >
>> > yes, this is fixed as Sean already told you in an earlier
>> update to this
>> > bugreport.
>> >
>> > Derick
>> >
>> > On 3 Jul 2001 [EMAIL PROTECTED] wrote:
>> >
>> > > ID: 11796
>> > > User Update by: [EMAIL PROTECTED]
>> > > Status: Closed
>> > > Bug Type: Unknown/Other Function
>> > > Operating system: Linux
>> > > PHP Version: 4.0.5
>> > > Description: get_meta_tags doesn't work when the title
>> tag consists of
>> single quote
>> > >
>> > > Hi, have another question.
>> > > Is this bug fixed in 4.0.6?
>> > > If so, I would rather upgrade my php to 4.0.6.
>> > >
>> > > Thanks.
>> > >
>> > >
>> > >
>> > >
>> > > Previous Comments:
>> >
>> >
>> --
>> 
>> -
>> > >
>> > > [2001-07-03 03:03:40] [EMAIL PROTECTED]
>> > >
>> > > nm, wrong entry
>> > >
>> >
>> >
>> --
>> 
>> -
>> > >
>> > > [2001-07-03 03:01:34] [EMAIL PROTECTED]
>> > >
>> > > >From the ChangeLog:
>> > >
>> > > 2001-03-06  Sean Bright  <[EMAIL PROTECTED]>
>> > >
>> > > * ext/standard/file.c: Typo.
>> > >
>> > > * ext/standard/file.c:
>> > > get_meta_tags now allows attributes that are not
>> quoted as well as
>> those
>> > > that are.  It follows the HTML 4.01 specification for
>> attribute
>> values
>> > > outlined here ->
>> http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
>> > >
>> > > You could have checked this yourself BTW.
>> > >
>> > > Derick
>> > >
>> >
>> >
>> --
>> 
>> -
>> > >
>> > > [2001-07-03 02:12:28] [EMAIL PROTECTED]
>> > >
>> > > Hi, have another question.
>> > > Is this bug fixed in 4.0.6?
>> > > If so, I would rather upgrade my php to 4.0.6.
>> > >
>> > > Thanks.
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> --
>> 
>> -
>> > >
>> > > [2001-07-02 04:12:45] [EMAIL PROTECTED]
>> > >
>> > > Either grab a snapshot form snaps.php.net or follow the
>> instructions on
>> getting the CVS version on: www.php.net/anoncvs.php
>> > >
>> > > Derick
>> > >
>> >
>> >
>> --
>> 
>> -
>> > >
>> > > [2001-07-02 04:11:02] [EMAIL PROTECTED]
>> > >
>> > > http://www.php.net/anoncvs.php
>> > >
>> > >
>> >
>> >
>> --
>> 
>> -
>> > >
>> > > The remainder of the comments for this report are too long.
>> > > To view the rest of the comments, please
>> > > view the bug report online.
>> > >
>> > > Full Bug description available at: http://bugs.php.net/?id=11796
>> > >
>> > >
>> > > --
>> > > 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]
>> > >
>> >
>> > Derick Rethans
>> >
>> >
>> -
>> > PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>> >  SRM: Site Resource Manager - www.vl-srm.net
>> >
>> -
>> >
>>
>>
>> --
>> 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 addi

[PHP-DEV] Re: snapshots are not created.

[Sascha Schumann]

On Tue, 3 Jul 2001, Jani Taskinen wrote:

>
> I doubt your change is in any of those snapshots..
> Last one of them was created on 11th of June.

Thanks for noticing this.  The permission problem has been
fixed.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
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 #11862: if ($submit) {

[jenshej1010]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.6
PHP Bug Type: *General Issues
Bug description:  if ($submit) {

It could be me, but after installing 406,(i run apache 1.3.20) the script where i use 
the "if ($submit) {" don't work. It's says! Warning: Undefined variable: submit in 
c:\programmer\apache group\apache\htdocs\signup.php on line 5

line 5 = if ($submit) {

When i put it on my server it works fine.

If it's me that done something wrong, then i'm sorry.

(it worked before installing 406)

this is the first version of php4 i have installed.


-- 
Edit Bug report at: http://bugs.php.net/?id=11862&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 #11862 Updated: if ($submit) {

[derick]

ID: 11862
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Set your error level to "E_ALL & ~E_NOTICE" and it will go
away. This is not a bug.

Derick

Previous Comments:
---

[2001-07-03 14:53:33] [EMAIL PROTECTED]

It could be me, but after installing 406,(i run apache 1.3.20) the script where i use 
the "if ($submit) {" don't work. It's says! Warning: Undefined variable: submit in 
c:programmerapache groupapachehtdocssignup.php on line 5

line 5 = if ($submit) {

When i put it on my server it works fine.

If it's me that done something wrong, then i'm sorry.

(it worked before installing 406)

this is the first version of php4 i have installed.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11862&edit=2


-- 
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 #11862 Updated: if ($submit) {

[jenshej1010]

ID: 11862
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *General Issues
Operating system: Win98
PHP Version: 4.0.6
Description: if ($submit) {

I took the php.ini from the zip version of 406.

And know i works. So i guess the installer did something wrong!

Previous Comments:
---

[2001-07-03 15:09:13] [EMAIL PROTECTED]

Set your error level to "E_ALL & ~E_NOTICE" and it will go
away. This is not a bug.

Derick

---

[2001-07-03 14:53:33] [EMAIL PROTECTED]

It could be me, but after installing 406,(i run apache 1.3.20) the script where i use 
the "if ($submit) {" don't work. It's says! Warning: Undefined variable: submit in 
c:programmerapache groupapachehtdocssignup.php on line 5

line 5 = if ($submit) {

When i put it on my server it works fine.

If it's me that done something wrong, then i'm sorry.

(it worked before installing 406)

this is the first version of php4 i have installed.

---


Full Bug description available at: http://bugs.php.net/?id=11862


-- 
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] PSPELL with PHP

[Lindsey Simon]

Seems to work correctly in the examples. I tried a few words and things seemed to go
well.. So I'm guessing it was able to load the dictionary, though from the php API it
still can't. hmm...
-l

Vlad Krupin in message Re: [PHP-DEV] PSPELL with PHP (Tue, 07/03 10:13):

> quite likely you missed something simple. Can you do the following?
> 1. go into pspell/example directory
> 2. do 'make example-c
> 3. do 'su nobody'
> 4. run './example-c en' (or whichever language you use)
> 5. try to spellcheck a word, e.g. 's helllo'
> And see what happens. If this does not succeed, you probably did not 
> install pspell or aspell correctly. Otherwise we'll have to do some more 
> problem hunting.
> 
> I never really tried to do anything more than just a basic install of 
> the spellchecker (e.g. different dictionaries, languages, etc.), so I 
> might be able to help you a bit if it is not installed correctly, but 
> not much.
> 
> Vlad
> 
> 
> 
> Lindsey Simon wrote:
> 
> >I've just compiled and installed php-4.0.6 --with-pspell support. However,
> >the pspell_new function gives me the following error:
> >
> >Warning: PSPELL couldn't open the dictionary. reason: I'm sorry I can't find any
> >suitable word lists for the language-tag "en".
> >
> >the line causing the error reads:
> >$pspell_config = pspell_config_create ("en","american");
> >$pspell_link = pspell_new_config($pspell_config);
> >
> >
> >I've created a file en-american.pwli in the pkgdata directory which points 
>absolutely
> >to a wordlist american-words.95.  
> >
> >I've been unable to find much clear documentation about the setup procedure for 
>pspell
> >with php and I suspect I'm missing something simple. Does anyone have a suggestion
> >that may help?
> >
> >-lindsey
> >
> >
> >
> 
> 
> 
> 
> -- 
> 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] lxr.php.net

[Andrei Zmievski]

lxr.php.net is back up.
bonsai.php.net to follow shortly.

-Andrei

The church is near but the road is icy;
the bar is far away but I will walk carefully. -- Russian proverb

-- 
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] New pow-function

[Jeroen van Wolffelaar]

Hi,

I've rewritten the pow(base,exp) function. It is attached.

In stead of a mere call to the c-lib function pow, this one actually does
something more smart. This is to protect those people not knowing that there
is huge difference between raising to an integer power and raising to a
fractional power. It will give sensible errors rather than bogus results.

It will also return integer when possible, i.e. pow(5,5) will return the
INTEGER 3125.

Read the new function for more info, it's richly commented, and for any
questions: just mail me.

IMPORTANT: I didn't test it yet, I'm not even sure there are no compile
errors.
(My linux machine doesn't have libtool 1.4 :-(( )

Greetz,
Jeroen

 new_pow_func.c

-- 
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] New pow-function

[Andrei Zmievski]

On Tue, 03 Jul 2001, Jeroen van Wolffelaar wrote:
> Hi,
> 
> I've rewritten the pow(base,exp) function. It is attached.
> 
> In stead of a mere call to the c-lib function pow, this one actually does
> something more smart. This is to protect those people not knowing that there
> is huge difference between raising to an integer power and raising to a
> fractional power. It will give sensible errors rather than bogus results.
> 
> It will also return integer when possible, i.e. pow(5,5) will return the
> INTEGER 3125.
> 
> Read the new function for more info, it's richly commented, and for any
> questions: just mail me.
> 
> IMPORTANT: I didn't test it yet, I'm not even sure there are no compile
> errors.
> (My linux machine doesn't have libtool 1.4 :-(( )

Please use proper Z_* macros, that is Z_LVAL_PP(exp) instead of
Z_LVAL(*exp).

-Andrei

"In this age, which believes that there is a short cut to everything,
 the greatest lesson to be learned is that the most difficult way is, in
 the long run, the easiest."
-Henry Miller, The Books in My Life

-- 
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] New pow-function

[Jeroen van Wolffelaar]

> > IMPORTANT: I didn't test it yet, I'm not even sure there are no compile
> > errors.
> > (My linux machine doesn't have libtool 1.4 :-(( )

Hey, I can now compile :)

And there is an error, so ignore this for now :(

> Please use proper Z_* macros, that is Z_LVAL_PP(exp) instead of
> Z_LVAL(*exp).

Z_LVAL_P(exp) in this case, I assume?

> 
> -Andrei

Jeroen



-- 
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] New pow-function

[Andrei Zmievski]

On Tue, 03 Jul 2001, Jeroen van Wolffelaar wrote:
> 
> > > IMPORTANT: I didn't test it yet, I'm not even sure there are no compile
> > > errors.
> > > (My linux machine doesn't have libtool 1.4 :-(( )
> 
> Hey, I can now compile :)
> 
> And there is an error, so ignore this for now :(
> 
> > Please use proper Z_* macros, that is Z_LVAL_PP(exp) instead of
> > Z_LVAL(*exp).
> 
> Z_LVAL_P(exp) in this case, I assume?

You use *_PP variants for ** pointers, and _P for * pointers.

-Andrei

"Music expresses that which can not be said
 and on which it is impossible to be silent."
 -Victor Hugo

-- 
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] lxr.php.net

[Jason Greene]

kudos Andrei

- Original Message - 
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "PHP Developers" <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 2:37 PM
Subject: [PHP-DEV] lxr.php.net


> lxr.php.net is back up.
> bonsai.php.net to follow shortly.
> 
> -Andrei
> 
> The church is near but the road is icy;
> the bar is far away but I will walk carefully. -- Russian proverb
> 
> -- 
> 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]

Re: [PHP-DEV] New pow-function

[Jeroen van Wolffelaar]

> You use *_PP variants for ** pointers, and _P for * pointers.

k.

I've now fixed the compile problems, it will compile now.
Even better: it works :-)

See attachment.

Greetz,
Jeroen

 new_pow_func.c

-- 
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 #11863: Cannot connect to mysql server

[veins]

From: [EMAIL PROTECTED]
Operating system: Unix
PHP version:  4.0.6
PHP Bug Type: MySQL related
Bug description:  Cannot connect to mysql server

I am using php-4.0.6 with MySQL-3.23.39 and there seems to be a problem with 
connecting to the database server. Problem that didn't happen with any previous 
version (even php-4.0.5 that i was using till today). phpinfo() shows a correct 
configuration and correct path to the socket, mysql server works correctly from 
console and i'm not using the bundled libraries (tried them also and it gave the same 
error). This was reproductible under OpenBSD-2.7-stable, OpenBSD-2.8, 
OpenBSD-2.8-stable, OpenBSD-2.9, OpenBSD-2.9-stable, Linux Debian (current), Linux 
RedHat 7.0, Linux Slackware 7.1 and probably others.


Configuration flags of PHP are:

--with-apache=/usr/local/apache --with-mysql=/usr/local/mysqlc 
--with-openssl=/usr/local/ssl --with-gd=/usr/local/gd --with-jpeg-dir=/usr/local 
--with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-ttf=/usr/local 
--enable-apc --enable-calendar --enable-bcmath --enable-track-vars


MySQL related configuration directives in php.ini are:

mysql.allow_persistent = Off
mysql.max_persistent = 0
mysql.max_links = 1000
mysql.default_port = 3306
mysql.default_socket = /usr/local/mysqlc/var/mysql.sock
mysql.default_host = localhost


MySQL was compiled with the following flags:

--enable-static --localstatedir=/usr/local/mysqlc/var --with-libwrap=/usr 
--with-mysqld-user=mysqlc --with-unix-socket-path=/usr/local/mysqlc/var/mysql.sock 
--with-tcp-port=3306 --without-bench --without-mit-threads


Error returned:

Warning: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3

Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3


Script that returned the error:




By the way, if someone would care to write a patch for:
http://www.php.net/bugs.php?id=11767
I'd appreciate it cause i got poor C skills  ;p


-- 
Edit Bug report at: http://bugs.php.net/?id=11863&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] New pow-function

[Andrei Zmievski]

On Tue, 03 Jul 2001, Jeroen van Wolffelaar wrote:
> > You use *_PP variants for ** pointers, and _P for * pointers.
> 
> k.
> 
> I've now fixed the compile problems, it will compile now.
> Even better: it works :-)
> 
> See attachment.

And try to use ZEND_NUM_ARGS() wherever possible. Like here:

zend_get_parameters_ex(ZEND_NUM_ARGS(),&zbase,&zexp);


-Andrei

What's hard, in hacking as in fiction,
is not the writing, it's deciding what to write.
-- Neal Stephenson

-- 
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 #11863 Updated: Cannot connect to mysql server

[derick]

ID: 11863
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: MySQL related
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

It works fine here. Are you sure MySQl is actually running, and are the permissions on 
the socket correct?

Derick

Previous Comments:
---

[2001-07-03 16:28:24] [EMAIL PROTECTED]

I am using php-4.0.6 with MySQL-3.23.39 and there seems to be a problem with 
connecting to the database server. Problem that didn't happen with any previous 
version (even php-4.0.5 that i was using till today). phpinfo() shows a correct 
configuration and correct path to the socket, mysql server works correctly from 
console and i'm not using the bundled libraries (tried them also and it gave the same 
error). This was reproductible under OpenBSD-2.7-stable, OpenBSD-2.8, 
OpenBSD-2.8-stable, OpenBSD-2.9, OpenBSD-2.9-stable, Linux Debian (current), Linux 
RedHat 7.0, Linux Slackware 7.1 and probably others.


Configuration flags of PHP are:

--with-apache=/usr/local/apache --with-mysql=/usr/local/mysqlc 
--with-openssl=/usr/local/ssl --with-gd=/usr/local/gd --with-jpeg-dir=/usr/local 
--with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-ttf=/usr/local 
--enable-apc --enable-calendar --enable-bcmath --enable-track-vars


MySQL related configuration directives in php.ini are:

mysql.allow_persistent = Off
mysql.max_persistent = 0
mysql.max_links = 1000
mysql.default_port = 3306
mysql.default_socket = /usr/local/mysqlc/var/mysql.sock
mysql.default_host = localhost


MySQL was compiled with the following flags:

--enable-static --localstatedir=/usr/local/mysqlc/var --with-libwrap=/usr 
--with-mysqld-user=mysqlc --with-unix-socket-path=/usr/local/mysqlc/var/mysql.sock 
--with-tcp-port=3306 --without-bench --without-mit-threads


Error returned:

Warning: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3

Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3


Script that returned the error:




By the way, if someone would care to write a patch for:
http://www.php.net/bugs.php?id=11767
I'd appreciate it cause i got poor C skills  ;p

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11863&edit=2


-- 
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] New pow-function

[Jeroen van Wolffelaar]

> And try to use ZEND_NUM_ARGS() wherever possible. Like here:
>
> zend_get_parameters_ex(ZEND_NUM_ARGS(),&zbase,&zexp);

I'm fairly new to C, and surely new to the php-implementation, so I took
this from many, many other functions, where it was done that way... I
haven't noticed any function doing it like that :-)

But sure, I'll keep it in mind. Though this is faster. And pow isn't likely
to change it's number of parameters :).

>
> -Andrei
>
> What's hard, in hacking as in fiction,
> is not the writing, it's deciding what to write.
> -- Neal Stephenson


-- 
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 #11846 Updated: AL EJECUTAR MAKE MARCA ERROR

[derick]

ID: 11846
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Input from the MySQL team:

The MySQL code does assume that INT_MAX and INT_MIN are defined
somewhere.  We include  if it is found, and it should
have those macros defined in it.

It may be a communication problem between the PHP configure and
the MySQL code; if for some reason HAVE_LIMITS_H is not being
defined, then we won't include .  But it looks like
PHP is using HAVE_LIMITS_H in several places itself, so that
shouldn't be the case.  Also, INT_MAX is used in the pcrelib and
oci8 extensions, so I don't think it's strictly a MySQL issue.

It looks like maybe the user's limits.h is defective.  Or maybe
the compiler is not installed correctly, or something.  It would
be up to the user, I think, to track down what happened to
INT_MAX on his system.  I suppose we could add a test for it in
our config stuff, but I really think that's the wrong fix.

Tim



Can you take a look at your limits.h file?

Derick

Previous Comments:
---

[2001-07-03 09:44:42] [EMAIL PROTECTED]

again error in other lines
command compile

$./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19 
--enable-sysvsem --enable-sysvshm --without-mysql
   LAST LINES 
cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/posix 
-I/admvos/sistgczo/php-4.0.6/main -I/admvos/sistgczo/php-4.0.6 
-I/admvos/apache/apache_1.3.19/src/include -I/admvos/apache/apache_1.3.19/src/os/unix 
-I/admvos/sistgczo/php-4.0.6/Zend -I/usr/informix/incl/esql 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmlparse -I/admvos/sistgczo/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c posix.c && touch posix.lo
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L185/C5(#257):   '=' 
encountered where '==' may have been intended.
w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L198/C4(#257):   '=' 
encountered where '==' may have been intended.
w "/admvos/sistgczo/php-4.0.6/ext/standard/php_string.h",L125/C5(#257): '=' 
encountered where '==' may have been intended.
E "posix.c",L357/C17(#237): NGROUPS_MAX: Identifier is undeclared.
E "posix.c",L357/C9(#445):  gidlist
|Type of variable is an array of zero length.
E "posix.c",L361/C21(#237): NGROUPS_MAX: Identifier is undeclared.
w (#657):   (info) How referenced files were included:
|File /admvos/sistgczo/php-4.0.6/Zend/zend_execute.h from 
|/admvos/sistgczo/php-4.0.6/Zend/zend_API.h from /admvos/sistgczo/php-4.0.6/main/php.h 
|from posix.c.
|File /admvos/sistgczo/php-4.0.6/ext/standard/php_string.h from posix.c.
3 user errors   4 warnings
*** Error code 3 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.

THANKS...

---

[2001-07-03 02:53:35] [EMAIL PROTECTED]

For now you can disable the use of MySQL by adding --withot-mysql to your configire 
line.

./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19
--enable-sysvsem --enable-sysvshm --without-mysql

I reported this to the MySQL folks, as

---

[2001-07-02 17:43:58] [EMAIL PROTECTED]

THE VERSION installed version at the moment is 3.0.18 without problem. 
not compile with mysql, use to informix database
the procedure is
1.- 
$ cd apache_1.3.19
$ ./configure  # OK NO ERROR
$ cd ../php4.0.6
$ cd php-4.0.6
$ ./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19 
--enable-sysvsem --enable -sysvshm# OK NO ERROR
$ make 
Making all in libmysql
cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/mysql/libmysql 
-I/admvos/sistgczo/php-4.0.6/main -I/admvos/sistgczo/php-4.0.6 
-I/admvos/apache/apache_1.3.19/src/include -I/admvos/apache/apache_1.3.19/src/os/unix 
-I/admvos/sistgczo/php-4.0.6/Zend -I/usr/informix/incl/esql 
-I/admvos/sistgczo/php-4.0.6/ext/mysql/libmysql 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmlparse -I/admvos/sistgczo/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c my_init.c && touch my_init.lo
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
E "my_init.c",L44/C7(#237): INT_MAX: Identifier is undeclared.
w "my_init.c",L100/C9(#257):'=' encountered where '==' may have been intended.
1 user error   1 warning
*** Error code 1 (bu21)

make: fatal error.

[PHP-DEV] Bug #11846 Updated: AL EJECUTAR MAKE MARCA ERROR

[derick]

ID: 11846
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Compile Failure
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:



Previous Comments:
---

[2001-07-03 09:44:42] [EMAIL PROTECTED]

again error in other lines
command compile

$./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19 
--enable-sysvsem --enable-sysvshm --without-mysql
   LAST LINES 
cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/posix 
-I/admvos/sistgczo/php-4.0.6/main -I/admvos/sistgczo/php-4.0.6 
-I/admvos/apache/apache_1.3.19/src/include -I/admvos/apache/apache_1.3.19/src/os/unix 
-I/admvos/sistgczo/php-4.0.6/Zend -I/usr/informix/incl/esql 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmlparse -I/admvos/sistgczo/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c posix.c && touch posix.lo
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L185/C5(#257):   '=' 
encountered where '==' may have been intended.
w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L198/C4(#257):   '=' 
encountered where '==' may have been intended.
w "/admvos/sistgczo/php-4.0.6/ext/standard/php_string.h",L125/C5(#257): '=' 
encountered where '==' may have been intended.
E "posix.c",L357/C17(#237): NGROUPS_MAX: Identifier is undeclared.
E "posix.c",L357/C9(#445):  gidlist
|Type of variable is an array of zero length.
E "posix.c",L361/C21(#237): NGROUPS_MAX: Identifier is undeclared.
w (#657):   (info) How referenced files were included:
|File /admvos/sistgczo/php-4.0.6/Zend/zend_execute.h from 
|/admvos/sistgczo/php-4.0.6/Zend/zend_API.h from /admvos/sistgczo/php-4.0.6/main/php.h 
|from posix.c.
|File /admvos/sistgczo/php-4.0.6/ext/standard/php_string.h from posix.c.
3 user errors   4 warnings
*** Error code 3 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.

THANKS...

---

[2001-07-03 02:53:35] [EMAIL PROTECTED]

For now you can disable the use of MySQL by adding --withot-mysql to your configire 
line.

./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19
--enable-sysvsem --enable-sysvshm --without-mysql

I reported this to the MySQL folks, as

---

[2001-07-02 17:43:58] [EMAIL PROTECTED]

THE VERSION installed version at the moment is 3.0.18 without problem. 
not compile with mysql, use to informix database
the procedure is
1.- 
$ cd apache_1.3.19
$ ./configure  # OK NO ERROR
$ cd ../php4.0.6
$ cd php-4.0.6
$ ./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19 
--enable-sysvsem --enable -sysvshm# OK NO ERROR
$ make 
Making all in libmysql
cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/mysql/libmysql 
-I/admvos/sistgczo/php-4.0.6/main -I/admvos/sistgczo/php-4.0.6 
-I/admvos/apache/apache_1.3.19/src/include -I/admvos/apache/apache_1.3.19/src/os/unix 
-I/admvos/sistgczo/php-4.0.6/Zend -I/usr/informix/incl/esql 
-I/admvos/sistgczo/php-4.0.6/ext/mysql/libmysql 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmlparse -I/admvos/sistgczo/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c my_init.c && touch my_init.lo
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
E "my_init.c",L44/C7(#237): INT_MAX: Identifier is undeclared.
w "my_init.c",L100/C9(#257):'=' encountered where '==' may have been intended.
1 user error   1 warning
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.# THE LAST 25 LINES
$
THE VERSION installed version at the moment is 3.0.18 without problem. 

THANKS  GRACIAS

---

[2001-07-02 15:18:00] [EMAIL PROTECTED]

You get this error during the compilation of the mysql client libraries that are 
bundled with PHP.
Can you compile MySQL without problems? And can you possibly try gcc for the 
compilation of PHP?
What is you configure line?

Derick

---

[2001-07-02 15:15:00] [EMAIL PROTECTED]

NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
E "my_init.c",L44/C7(#237): INT

Re: [PHP-DEV] New pow-function

[Andrei Zmievski]

On Tue, 03 Jul 2001, Jeroen van Wolffelaar wrote:
> > And try to use ZEND_NUM_ARGS() wherever possible. Like here:
> >
> > zend_get_parameters_ex(ZEND_NUM_ARGS(),&zbase,&zexp);
> 
> I'm fairly new to C, and surely new to the php-implementation, so I took
> this from many, many other functions, where it was done that way... I
> haven't noticed any function doing it like that :-)
> 
> But sure, I'll keep it in mind. Though this is faster. And pow isn't likely
> to change it's number of parameters :).

ZEND_NUM_ARGS() is a preprocessor macro that expands to the number of
arguments passed to the function -- it's not any slower than specifying
a constant.

-Andrei

If you find a job that you love, you'll
never work another day in your life.
 - Mark Jackson

-- 
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 #11863 Updated: Cannot connect to mysql server

[veins]

ID: 11863
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: MySQL related
Operating system: Unix
PHP Version: 4.0.6
Description: Cannot connect to mysql server

Yeah, the server is actually running as i can connect to it from console. The socket 
is set srwxrwxrwx so it is also ok i presume.
The exact same configuration used to work with php-4.0.5 :/

Previous Comments:
---

[2001-07-03 16:32:07] [EMAIL PROTECTED]

It works fine here. Are you sure MySQl is actually running, and are the permissions on 
the socket correct?

Derick

---

[2001-07-03 16:28:24] [EMAIL PROTECTED]

I am using php-4.0.6 with MySQL-3.23.39 and there seems to be a problem with 
connecting to the database server. Problem that didn't happen with any previous 
version (even php-4.0.5 that i was using till today). phpinfo() shows a correct 
configuration and correct path to the socket, mysql server works correctly from 
console and i'm not using the bundled libraries (tried them also and it gave the same 
error). This was reproductible under OpenBSD-2.7-stable, OpenBSD-2.8, 
OpenBSD-2.8-stable, OpenBSD-2.9, OpenBSD-2.9-stable, Linux Debian (current), Linux 
RedHat 7.0, Linux Slackware 7.1 and probably others.


Configuration flags of PHP are:

--with-apache=/usr/local/apache --with-mysql=/usr/local/mysqlc 
--with-openssl=/usr/local/ssl --with-gd=/usr/local/gd --with-jpeg-dir=/usr/local 
--with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-ttf=/usr/local 
--enable-apc --enable-calendar --enable-bcmath --enable-track-vars


MySQL related configuration directives in php.ini are:

mysql.allow_persistent = Off
mysql.max_persistent = 0
mysql.max_links = 1000
mysql.default_port = 3306
mysql.default_socket = /usr/local/mysqlc/var/mysql.sock
mysql.default_host = localhost


MySQL was compiled with the following flags:

--enable-static --localstatedir=/usr/local/mysqlc/var --with-libwrap=/usr 
--with-mysqld-user=mysqlc --with-unix-socket-path=/usr/local/mysqlc/var/mysql.sock 
--with-tcp-port=3306 --without-bench --without-mit-threads


Error returned:

Warning: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3

Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3


Script that returned the error:




By the way, if someone would care to write a patch for:
http://www.php.net/bugs.php?id=11767
I'd appreciate it cause i got poor C skills  ;p

---


Full Bug description available at: http://bugs.php.net/?id=11863


-- 
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] PSPELL with PHP

[Lindsey Simon]

Oddly, Pspell and Aspell seem to work properly, but the pspell_new function can't load
the "en" dict. in the pspell/examples dir I can run the ./example.c en fine. 

I'm recompiling apache with php again right now to see if it may have to do with the
--with-pspell path I was giving. 
-l

Justin Plock in message Re: [PHP-DEV] PSPELL with PHP (Tue, 07/03 16:29):

> yea, I had a similiar problem trying to get this to work as well, here's the
> email i received from Vlad (author of the pspell php library) which seemed
> to work for me. (I was attempting to install both pspell and aspell from the
> freebsd ports tree).  See if this gives any insight, hehe:
> 
> 
> ---
> I bet you did not run the 'add-modules' script. The steps to properly build
> the thing are:
> First, in pspell directory:
>  ./configure
>  make
>  make install
> 
> Then, in aspell directory
> ./configure
> make
> make install
> 
> Finally, go back to pspell directory and do
> cd modules
> ./add-modules
> cd ..
> make
> make install
> 
> That last step is probably what you missed, at least, that gave me similar
> problems. Also, make sure that the directory where aspell and pspell place
> their shared files is amond the directories where your ldconfig will look
> into (I do not know how this is done in BSD)
> 
> This solves the chicken-and-egg problem when you can't build aspell without
> having pspell in place, yet pspell needs to know that aspell (or ispell)
> exists to function properly. It is also described in pspell README.
> 
> ---
> 
> Hope that helps,
> Justin.
> 
> 
> - Original Message -
> From: "Lindsey Simon" <[EMAIL PROTECTED]>
> To: "Justin Plock" <[EMAIL PROTECTED]>
> Sent: Tuesday, July 03, 2001 4:17 PM
> Subject: Re: [PHP-DEV] PSPELL with PHP
> 
> 
> > yeah, and pspell and aspell seem to be working fine. which is odd..
> >
> > Justin Plock in message RE: [PHP-DEV] PSPELL with PHP (Tue, 07/03 10:42):
> >
> > > This message was sent from Geocrawler.com by "Justin Plock"
> <[EMAIL PROTECTED]>
> > >
> > > Did you compile aspell into pspell?
> > >
> > > -Justin Plock
> > >
> > >
> > > ---
> > > I've just compiled and installed php-4.0.6 --with-
> > > pspell support. However,
> > > the pspell_new function gives me the following
> > > error:
> > >
> > > Warning: PSPELL couldn't open the dictionary.
> > > reason: I'm sorry I can't find any
> > > suitable word lists for the language-tag "en".
> > >
> > > the line causing the error reads:
> > > $pspell_config = pspell_config_create
> > > ("en","american");
> > > $pspell_link = pspell_new_config($pspell_config);
> > >
> > >
> > > I've created a file en-american.pwli in the
> > > pkgdata directory which points absolutely
> > > to a wordlist american-words.95.
> > >
> > > I've been unable to find much clear documentation
> > > about the setup procedure for pspell
> > > with php and I suspect I'm missing something
> > > simple. Does anyone have a suggestion
> > > that may help?
> > >
> > > -lindsey
> > >
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, e-mail: php-dev-
> > > [EMAIL PROTECTED]
> > > For additional commands, e-mail: php-dev-
> > > [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail: php-
> > > [EMAIL PROTECTED]
> > >
> > >
> > >
> > > Geocrawler.com - The Knowledge Archive
> >

-- 
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 #11863 Updated: Cannot connect to mysql server

[veins]

ID: 11863
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating system: Unix
PHP Version: 4.0.6
Description: Cannot connect to mysql server

Yeah, the server is actually running as i can connect to it from console. The socket 
is set srwxrwxrwx so it is also ok i presume.
The exact same configuration used to work with php-4.0.5 :/

Previous Comments:
---

[2001-07-03 16:41:17] [EMAIL PROTECTED]

Yeah, the server is actually running as i can connect to it from console. The socket 
is set srwxrwxrwx so it is also ok i presume.
The exact same configuration used to work with php-4.0.5 :/

---

[2001-07-03 16:32:07] [EMAIL PROTECTED]

It works fine here. Are you sure MySQl is actually running, and are the permissions on 
the socket correct?

Derick

---

[2001-07-03 16:28:24] [EMAIL PROTECTED]

I am using php-4.0.6 with MySQL-3.23.39 and there seems to be a problem with 
connecting to the database server. Problem that didn't happen with any previous 
version (even php-4.0.5 that i was using till today). phpinfo() shows a correct 
configuration and correct path to the socket, mysql server works correctly from 
console and i'm not using the bundled libraries (tried them also and it gave the same 
error). This was reproductible under OpenBSD-2.7-stable, OpenBSD-2.8, 
OpenBSD-2.8-stable, OpenBSD-2.9, OpenBSD-2.9-stable, Linux Debian (current), Linux 
RedHat 7.0, Linux Slackware 7.1 and probably others.


Configuration flags of PHP are:

--with-apache=/usr/local/apache --with-mysql=/usr/local/mysqlc 
--with-openssl=/usr/local/ssl --with-gd=/usr/local/gd --with-jpeg-dir=/usr/local 
--with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-ttf=/usr/local 
--enable-apc --enable-calendar --enable-bcmath --enable-track-vars


MySQL related configuration directives in php.ini are:

mysql.allow_persistent = Off
mysql.max_persistent = 0
mysql.max_links = 1000
mysql.default_port = 3306
mysql.default_socket = /usr/local/mysqlc/var/mysql.sock
mysql.default_host = localhost


MySQL was compiled with the following flags:

--enable-static --localstatedir=/usr/local/mysqlc/var --with-libwrap=/usr 
--with-mysqld-user=mysqlc --with-unix-socket-path=/usr/local/mysqlc/var/mysql.sock 
--with-tcp-port=3306 --without-bench --without-mit-threads


Error returned:

Warning: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3

Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket 
'/usr/local/mysqlc/var/mysql.sock' (13) in /home/www/k/kheos.net/test.php on line 3


Script that returned the error:




By the way, if someone would care to write a patch for:
http://www.php.net/bugs.php?id=11767
I'd appreciate it cause i got poor C skills  ;p

---


Full Bug description available at: http://bugs.php.net/?id=11863


-- 
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 #11864: php_value in .htaccess-files makes ordinary .html-files be parsed through php.

[php]

From: [EMAIL PROTECTED]
Operating system: Linux tall 2.4.2 #4 Wed Feb 28 17:19:58 CET 2001 i686 unknown
PHP version:  4.0.5
PHP Bug Type: Apache related
Bug description:  php_value in .htaccess-files makes ordinary .html-files be parsed 
through php.

I added this in a .htaccess-file.

php_value include_path .:/home/sites/www.senab.com/web/include

When looking at a .html-file it produces a php-error.
Parse error: parse error in 
/home/sites/senab/web/kunder/6210nokia4/produkter/k1g43p43.html on line 62

When I removed the line the file was treated as any other .html-file. No errors.

'./configure' '--prefix=/usr/local/php' '--with-pgsql=/usr/local/pgsql' 
'--enable-trans-sid' '--with-mm=/usr/local/mm' '--with-sockets' '--with-ftp' 
'--enable-calendar' '--with-apxs=/usr/local/bin/apxs' '--with-imap=/usr/local/c-client'

Best regards
Per-Olof Pettersson




-- 
Edit Bug report at: http://bugs.php.net/?id=11864&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] PSPELL with PHP

[Vlad Krupin]

Please, tell me what
1. your configure line is for php
2. configure lines for aspell and pspell
3. location of your dictionaries

Another thing. You said:

>I've created a file en-american.pwli in the
>pkgdata directory which points absolutely
>to a wordlist american-words.95.

What's pkgdata? I have not heard of such a thing. And neither do I have 
en-american.pwli on my system. On my system .pwli files are located in 
/usr/local/share/pspell (default location) and the one you probably want 
is called en-american-aspell.pwli with the record in it referencing 
/usr/local/lib/aspell/american. Note the -aspell part of the filename. 
Or file en-aspell.pwli that is used for straight (non-americanized) 
English that references /usr/local/lib/aspell/english. BTW, this is the 
library you used when running the test ./example-c from pspell.

Anyways, rather than figuring out the mysteries of the spellchecker, it 
is the easiest to do a default install of pspell and aspell, without 
creating any new dictionaries by hand and all that kind of stuff. Once 
you have this working with php, you can wonder off and do whatever 
custom stuff you need..

Vlad


Lindsey Simon wrote:

>Oddly, Pspell and Aspell seem to work properly, but the pspell_new function can't load
>the "en" dict. in the pspell/examples dir I can run the ./example.c en fine. 
>
>I'm recompiling apache with php again right now to see if it may have to do with the
>--with-pspell path I was giving. 
>-l
>
>Justin Plock in message Re: [PHP-DEV] PSPELL with PHP (Tue, 07/03 16:29):
>
>>yea, I had a similiar problem trying to get this to work as well, here's the
>>email i received from Vlad (author of the pspell php library) which seemed
>>to work for me. (I was attempting to install both pspell and aspell from the
>>freebsd ports tree).  See if this gives any insight, hehe:
>>
>>
>>---
>>I bet you did not run the 'add-modules' script. The steps to properly build
>>the thing are:
>>First, in pspell directory:
>> ./configure
>> make
>> make install
>>
>>Then, in aspell directory
>>./configure
>>make
>>make install
>>
>>Finally, go back to pspell directory and do
>>cd modules
>>./add-modules
>>cd ..
>>make
>>make install
>>
>>That last step is probably what you missed, at least, that gave me similar
>>problems. Also, make sure that the directory where aspell and pspell place
>>their shared files is amond the directories where your ldconfig will look
>>into (I do not know how this is done in BSD)
>>
>>This solves the chicken-and-egg problem when you can't build aspell without
>>having pspell in place, yet pspell needs to know that aspell (or ispell)
>>exists to function properly. It is also described in pspell README.
>>
>>---
>>
>>Hope that helps,
>>Justin.
>>
>>
>>- Original Message -
>>From: "Lindsey Simon" <[EMAIL PROTECTED]>
>>To: "Justin Plock" <[EMAIL PROTECTED]>
>>Sent: Tuesday, July 03, 2001 4:17 PM
>>Subject: Re: [PHP-DEV] PSPELL with PHP
>>
>>
>>>yeah, and pspell and aspell seem to be working fine. which is odd..
>>>
>>>Justin Plock in message RE: [PHP-DEV] PSPELL with PHP (Tue, 07/03 10:42):
>>>
This message was sent from Geocrawler.com by "Justin Plock"

>><[EMAIL PROTECTED]>
>>
Did you compile aspell into pspell?

-Justin Plock


---
I've just compiled and installed php-4.0.6 --with-
pspell support. However,
the pspell_new function gives me the following
error:

Warning: PSPELL couldn't open the dictionary.
reason: I'm sorry I can't find any
suitable word lists for the language-tag "en".

the line causing the error reads:
$pspell_config = pspell_config_create
("en","american");
$pspell_link = pspell_new_config($pspell_config);


I've created a file en-american.pwli in the
pkgdata directory which points absolutely
to a wordlist american-words.95.

I've been unable to find much clear documentation
about the setup procedure for pspell
with php and I suspect I'm missing something
simple. Does anyone have a suggestion
that may help?

-lindsey



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



Geocrawler.com - The Knowledge Archive

>




-- 
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] [patch] New pow function

[Jeroen van Wolffelaar]

Hi,

I've fixed some bugs in the function, and believe it is now correct. It's
best to come up with a whole bunch of tests, since there are 25 conditional
expressions in it, for 25 different cases... This is due to the nature of
pow(), and the fact it is now overloaded. pow(0,0) is now fixed to return 1,
as it should, and not 0 (???).

The tests will follow soon. I think it's important to test it on platforms
with 64-bit longs.

(by the way, this function replaces the one in php4/ext/standard/math.c)

If nobody reports any problems, can someone commit it? I don't have the
karma.

Greetz,
Jeroen


 new_pow_func.c

-- 
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 #11765 Updated: Warning: MySQL: Unable to save result set in

[root]

ID: 11765
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating system: redhat-6.2
PHP Version: 4.0.6
Description: Warning: MySQL: Unable to save result set in

I upgraded to mysql-3.23.39 and recompiled php-4.0.6 but nothing changed.

Previous Comments:
---

[2001-06-28 21:25:12] [EMAIL PROTECTED]

BTW : This error occur on ALL OF my scripts after I had upgraded my php from 4.0.3 to 
4.0.6

---

[2001-06-28 21:21:26] [EMAIL PROTECTED]

Yes I use Use mysql_query() / mysql_select_db() instead of mysql_db_query().
Both mysql_errno() and mysql_error() return NOTHING.
The query was successful exectued by mysql.(I can find the query reselt in mysql 
database)
But why php generated an error?


---

[2001-06-28 13:16:05] [EMAIL PROTECTED]

Try adding this lines after each mysql function:

echo mysql_errno().": ".mysql_error()."";

This way you should get the reason why it doesn't work.

And FYI: Use mysql_query() / mysql_select_db()
instead of mysql_db_query().

--Jani


---

[2001-06-27 23:37:47] [EMAIL PROTECTED]

The script(error.php) is :




The result in browser is:


Warning: MySQL: Unable to save result set in /home/0/admin/error.php on line 7


But I just found that NO error in command line

root@localhost # php ./error.php
X-Powered-By: PHP/4.0.6
Content-type: text/html




---

[2001-06-27 23:06:49] [EMAIL PROTECTED]

I'm getting the following error message when I execute a query (such as insert or 
delete
or update but not select) that doesn't produce any results:

Warning: MySQL: Unable to save result set in /path/to/sql.php3
on line 33

MySQL said NOTHING and the query was successful executed.

I have set "display_errors = Off" in my php.ini, so no warnings should be shown
, but php script can not go on at the line where the Warnning should display.



I configured php with the following command:

./configure  --with-mysql=/usr/local/mysql --enable-track-vars 
--with-gd=../../gd/gd1.3
--with-ftp --with-imap=../../mail/imap/imap-4.7c --enable-memory-limit
--with-pgsql=/usr/local/pgsql

MySQL is version 3.23.38 and PostgreSQL is version 7.1.2 

and compiled with th following command:

./configure  --prefix=/usr/local/mysql --with-mysqld-user=mysql --with-charset=gb2312
--with-extra-charsets=all

./configure  --enable-multibyte --enable-unicode-conversion --with-perl
--with-openssl=/usr/local/ssl --enable-odbc --with-CXX


BTW : The script is perfect on mysql-php-4.0.3pl1 and postgreSQL-php-4.0.6 .

---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=11765


-- 
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] Security?

[sterling hughes]

Ah well, I'm guessing most people have already seen this, still, I
couldn't help passing it along...  There are some good points (nothing
we haven't discussed before) and some pretty bad points as well.

-Sterling


<<<-

   A Study In Scarlet
  Exploiting Common Vulnerabilities in PHP Applications

Shaun Clowes
   SecureReality

"A reprint of reminisces from the Blackhat Briefings Asia 2001"

<<<-

--- < Table of Contents > --

1. Introduction
2. Caveats and Scope
3. Global Variables
4. Remote Files
5. File Upload
6. Library Files
7. Session Files
8. Loose Typing And Associative Arrays
9. Target Functions
10. Protecting PHP
11. Responsibility - Language vs Programmer
12. Other

"I could imagine his giving a friend a little pinch of the latest vegetable
alkaloid, not out of malevolence, you understand, but simply out of a spirit
of inquiry in order to have an accurate idea of the effects." - Stamford

--- < 1. Introduction > 

This paper is based on my speech during the Blackhat briefings in Singapore
and Hong Kong in April 2001. The speech was entitled "Breaking In Through
the Front Door - The impact of Web Applications and Application Service
Provision on Traditional Security Models". It initially discussed the trend
towards Web Applications (and ASP) and the holes in traditional security
methodology exposed by this trend. However, that's a long and boring
discussion so I'll save it for the policy makers.

The rest of the speech was spent talking about PHP. For those reading this
paper who don't know what PHP is, PHP stands for "PHP Hypertext
Preprocessor". It's a programming language (designed specifically for the
Web) in which PHP code is embedded in web pages. When a client requests a
page, the Web Server first passes the page to the language interpreter so
the code can be executed, the resulting page is then returned to the client.

Obviously this approach is much more suited to the page by page nature of
web transactions than traditional CGI languages such as Perl and C. PHP (and
to some extent other Web Languages) has the following characteristics:
 + Interpreted
 + Fast Execution - The interpreter is embedded in the web server, no fork()
or setup overhead
 + Feature Rich - Hundreds of non trivial builtin functions
 + Simple Syntax - Non declared and loosely typed variables, 'wordy'
function names

Over the course of this paper I'm going to try to explain why I feel the
last two characteristics make applications written in PHP easy to attack and
hard to defend. Then I'll finish off with a rant about distribution of
'blame' when it comes to software security.

"You must study him, then ... you'll find him a knotty problem, though. I'll
wager he learns more about you than you about him." - Stamford

--- < 2. Caveats and Scope > ---

Almost all the observations in this paper refer to a default install of PHP
4.0.4pl1 (with MySQL, PostgreSQL, IMAP and OpenSSL support enabled) running
as a module under Apache 1.3.19 on a Linux machine. This of course means
that your mileage may vary, in particular, there have been many many
versions of PHP and they sometimes exhibit vastly different behaviour given
the same input.

Also, proponents of PHP tend to defend the language based on its extreme
configurability. I feel very confident the vast majority of users will not
modify the default PHP configuration at all, lest some of the amazing array
of freely available PHP software stop working. Thus I don't feel pressured
to defend my position based on configuration options, nonetheless I've
included a section about how to go defending PHP applications using these
configuration options.

Finally, some people deride this kind of work as 'trivial' or 'obvious',
particularly since I won't be discussing any specific vulnerabilities in
particular pieces of PHP software. To prove the risks are real and that even
programmer's that try hard fall into these traps 4 detailed advisories in
regards to specific pieces of vulnerable software will be released shortly
after this paper.

"I have to be careful ... for I dabble with poisons a good deal." - Sherlock
Holmes

--- < 3. Global Variables > 

As mentioned earlier, variables in PHP don't have to be declared, they're
automatically created the first time they are used. Nor are they
specifically typed, they're typed automatically based on the context in
which they are used. This is an extremely convenient way to do things from a
programmer's perspective (and is obviously a useful feature in a rap

Re: [PHP-DEV] Security?

[Rasmus Lerdorf]

On 4 Jul 2001, sterling hughes wrote:
> Ah well, I'm guessing most people have already seen this, still, I
> couldn't help passing it along...  There are some good points (nothing
> we haven't discussed before) and some pretty bad points as well.

A lot of these are rather silly and are actually present in other
scripting languages when they are used in a web environment.  Most of it
boils down to the fact that you cannot trust user data.  The fact that
user data is easier to get at in PHP doesn't really change the model.
Making it harder to get the user data doesn't help if this data is still
not checked and used incorrectly once you do get it.

But, I do think it would be worthwhile to go through these and add a
section to the documentation highlighting the pitfalls and explaining how
to avoid them.

(cc'ed phpdoc with the hope that somebody will step up to do so)

-Rasmus


<<<-

   A Study In Scarlet
  Exploiting Common Vulnerabilities in PHP Applications

Shaun Clowes
   SecureReality

"A reprint of reminisces from the Blackhat Briefings Asia 2001"

<<<-

--- < Table of Contents > --

1. Introduction
2. Caveats and Scope
3. Global Variables
4. Remote Files
5. File Upload
6. Library Files
7. Session Files
8. Loose Typing And Associative Arrays
9. Target Functions
10. Protecting PHP
11. Responsibility - Language vs Programmer
12. Other

"I could imagine his giving a friend a little pinch of the latest vegetable
alkaloid, not out of malevolence, you understand, but simply out of a spirit
of inquiry in order to have an accurate idea of the effects." - Stamford

--- < 1. Introduction > 

This paper is based on my speech during the Blackhat briefings in Singapore
and Hong Kong in April 2001. The speech was entitled "Breaking In Through
the Front Door - The impact of Web Applications and Application Service
Provision on Traditional Security Models". It initially discussed the trend
towards Web Applications (and ASP) and the holes in traditional security
methodology exposed by this trend. However, that's a long and boring
discussion so I'll save it for the policy makers.

The rest of the speech was spent talking about PHP. For those reading this
paper who don't know what PHP is, PHP stands for "PHP Hypertext
Preprocessor". It's a programming language (designed specifically for the
Web) in which PHP code is embedded in web pages. When a client requests a
page, the Web Server first passes the page to the language interpreter so
the code can be executed, the resulting page is then returned to the client.

Obviously this approach is much more suited to the page by page nature of
web transactions than traditional CGI languages such as Perl and C. PHP (and
to some extent other Web Languages) has the following characteristics:
 + Interpreted
 + Fast Execution - The interpreter is embedded in the web server, no fork()
or setup overhead
 + Feature Rich - Hundreds of non trivial builtin functions
 + Simple Syntax - Non declared and loosely typed variables, 'wordy'
function names

Over the course of this paper I'm going to try to explain why I feel the
last two characteristics make applications written in PHP easy to attack and
hard to defend. Then I'll finish off with a rant about distribution of
'blame' when it comes to software security.

"You must study him, then ... you'll find him a knotty problem, though. I'll
wager he learns more about you than you about him." - Stamford

--- < 2. Caveats and Scope > ---

Almost all the observations in this paper refer to a default install of PHP
4.0.4pl1 (with MySQL, PostgreSQL, IMAP and OpenSSL support enabled) running
as a module under Apache 1.3.19 on a Linux machine. This of course means
that your mileage may vary, in particular, there have been many many
versions of PHP and they sometimes exhibit vastly different behaviour given
the same input.

Also, proponents of PHP tend to defend the language based on its extreme
configurability. I feel very confident the vast majority of users will not
modify the default PHP configuration at all, lest some of the amazing array
of freely available PHP software stop working. Thus I don't feel pressured
to defend my position based on configuration options, nonetheless I've
included a section about how to go defending PHP applications using these
configuration options.

Finally, some people deride this kind of work as 'trivial' or 'obvious',
particularly since I won't be discussing any specific vulnerabilities in
particular pieces of PHP software. To prove the risks are real and that even
programmer's 

[PHP-DEV] Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt

[kpw]

ID: 10324
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: mcrypt related
Operating system: Linux PPC (yellow dog 1.2)
PHP Version: 4.0.4pl1
Description: reproducable seg fault during generic script exec with pgsql and mcrypt



Previous Comments:
---

[2001-07-03 10:48:42] [EMAIL PROTECTED]

Hi,

This still seems to be a problem in 4.0.6.  I'm pretty sure that it is caused by 
specific strings being passed into mycrypt, however, I'm not sure what string 
characteristics cause the problem.  

kpw

---

[2001-05-27 19:27:02] [EMAIL PROTECTED]

Should be fixed in CVS now. Fix will be in PHP 4.0.6.
If this happens with it too, reopen this bug report.

--Jani


---

[2001-04-14 09:54:47] [EMAIL PROTECTED]

here's the back trace (again without db symbols) of the crash when it happens after my 
script has completed execution:

Program received signal SIGSEGV, Segmentation fault.
0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111
3111malloc.c: No such file or directory.
(gdb) bt
#0  0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111
#1  0xfe20fb0 in __libc_free (mem=0xfebb380) at malloc.c:3023
#2  0xf01121c in ?? () from /etc/apache/libexec/libphp4.so
#3  0x0 in ?? ()
(gdb) 



---

[2001-04-14 09:46:01] [EMAIL PROTECTED]

I've rebuilt php with --enable-debug on (rm config.cache & cleaned the build dirs), 
but the db symbols still don't appear in the back trace.  I am using the standard 
build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this 
isn't working as expected.



---

[2001-04-14 07:38:40] [EMAIL PROTECTED]

Can you  try configuring php with --enable-debug, so that better backtraces can be 
made?

---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10324


-- 
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 #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt

[kpw]

ID: 10324
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Old-Bug Type: mcrypt related
Bug Type: Reproducible crash
Operating system: Linux PPC (yellow dog 1.2) and Redhat 6.8 x86
PHP Version: 4.0.6
Description: reproducable seg fault during generic script exec with pgsql and mcrypt

Here's the link to a script that exhibits this problem 100% of the time on my 
PPC/YellowDog server as well as a production machine at phpwebhosting.com:

http://www.jump9.com/_testcrypt.txt 


I've tried this under several version of php (including the current 4.0.6) as well as 
with every available release of libmcrypt (2.4.7-2.4.15) all without effect.  Given 
that I have the same problem on a production webserver at phpwebhosting as I do on my 
own homemade PPC linux box I'm guessing this is real problem...

Any thoughts would be greatly appreciated...


kpw 




Previous Comments:
---

[2001-07-03 11:28:04] [EMAIL PROTECTED]

Here's an example:

If encrypt the string "Reed, Phyllis" with the key "70094cc48e1a23bf6fec60c2db6e4b71" 
using blowfish in CBC mode mycrypt will seg fault.  However, if I change the string to 
"Reed,Phyllis" (no space) everything's fine.  Removing a chacter from the end (""Reed, 
Phylli") doesn't fix the problem though, so it's apparently not length related.

Very strange indeed...
kpw 

---

[2001-07-03 10:48:42] [EMAIL PROTECTED]

Hi,

This still seems to be a problem in 4.0.6.  I'm pretty sure that it is caused by 
specific strings being passed into mycrypt, however, I'm not sure what string 
characteristics cause the problem.  

kpw

---

[2001-05-27 19:27:02] [EMAIL PROTECTED]

Should be fixed in CVS now. Fix will be in PHP 4.0.6.
If this happens with it too, reopen this bug report.

--Jani


---

[2001-04-14 09:54:47] [EMAIL PROTECTED]

here's the back trace (again without db symbols) of the crash when it happens after my 
script has completed execution:

Program received signal SIGSEGV, Segmentation fault.
0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111
3111malloc.c: No such file or directory.
(gdb) bt
#0  0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111
#1  0xfe20fb0 in __libc_free (mem=0xfebb380) at malloc.c:3023
#2  0xf01121c in ?? () from /etc/apache/libexec/libphp4.so
#3  0x0 in ?? ()
(gdb) 



---

[2001-04-14 09:46:01] [EMAIL PROTECTED]

I've rebuilt php with --enable-debug on (rm config.cache & cleaned the build dirs), 
but the db symbols still don't appear in the back trace.  I am using the standard 
build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this 
isn't working as expected.



---

The remainder of the comments for this report are too long.
To view the rest of the comments, please
view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10324


-- 
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 #11780 Updated: udm_find makes php crash

[cedric]

ID: 11780
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: Unknown/Other Function
Operating system: Linux
PHP Version: 4.0.6
Description: udm_find makes php crash

Actually I did'nt specify the MySQL librairies path
for php compilation since I don't have any other Apache DSO's that are accessing 
MySQL.

Here's my configure line:

../configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --enable-trans-sid 
--with-curl --with-mnogosearch=/usr/local/bin/mnogosearch --enable-debug



Previous Comments:
---

[2001-07-03 14:35:22] [EMAIL PROTECTED]

User feedback:


 Hi Sergey !

Thanks a lot for your input.
It was actually already compiled that way.
However, you gave me an idea..
I've specified the path of the mysql binaries
( --with-mysql=/usr/local/mysql ) [for mnoGoSearch compil]
and now it seems to work fine !

The funny thing is that when I use only  --with-mysql, all the command line
tools
like the indexer are working fine and updates the databases accordingly !



I guess you used this on PHP configure too?
It's better to use the external MySQL libraries if there
are some other Apache DSO's or some library that also uses 
Mysql.

--Jani
 

---

[2001-06-29 02:07:12] [EMAIL PROTECTED]

Just got a new backtrace with httpd -X:

Program received signal SIGSEGV, Segmentation fault.
__libc_free (mem=0x1) at malloc.c:2914
malloc.c:2914: No such file or directory.
(gdb) bt
#0  __libc_free (mem=0x1) at malloc.c:2914
#1  0x403a0bf1 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#2  0x4039cb26 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#3  0x40415bfe in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#4  0x40415d6f in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#5  0x4042aa41 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#6  0x40393bdb in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#7  0x4037a2ae in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#8  0x40379137 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#9  0x4037a088 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#10 0x40395dd0 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#11 0x40366dbc in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#12 0x40375bc7 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#13 0x40386ce4 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#14 0x403838bf in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#15 0x40384218 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#16 0x40384248 in ?? () from /usr/local/apache-1.3.19/libexec/libphp4.so
#17 0x806ba5f in ap_invoke_handler ()
#18 0x807f375 in process_request_internal ()
#19 0x807f3d4 in ap_process_request ()
#20 0x8076871 in child_main ()
#21 0x80769fc in make_child ()
#22 0x8076b57 in startup_children ()
#23 0x8077154 in standalone_main ()
#24 0x80779b3 in main ()


---

[2001-06-29 01:32:31] [EMAIL PROTECTED]

BTW, if it can help, I'm using mnoGoSearch 3.1.16
and MySQL 3.23.35

---

[2001-06-28 10:05:25] [EMAIL PROTECTED]

To reproduce the problem :


Hello World
";
else
echo "Agent OK";
$res = udm_find( $udm_agent, "word" );
?>


Important notice: It seems to crash ONLY when the word
belongs the dictionary (dict table).
(This seems to prove that the udm_agent is well-defined)

Configuration :
./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --enable-trans-sid 
--with-curl --with-mnogosearch=/usr/local/bin/mnogosearch --enable-debug

Apache 1.3.19

Backtrace:

#0  _dl_lookup_versioned_symbol (undef_name=0x804bf7a "unlink", ref=0xbd18, 
symbol_scope=0x0, 
reference_name=0x40010187 "", version=0x40151048, reloc_type=7) at do-lookup.h:82
#1  0x40009cfa in fixup (l=0x40013368, reloc_offset=1668) at dl-runtime.c:75
#2  0x40009e70 in _dl_runtime_resolve () at dl-runtime.c:170
#3  0x80779b3 in main ()

---


Full Bug description available at: http://bugs.php.net/?id=11780


-- 
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 #11865: apxs: command not found

[arcie]

From: [EMAIL PROTECTED]
Operating system: Redhat 7.0
PHP version:  4.0.6
PHP Bug Type: Compile Problem
Bug description:  apxs: command not found

I wasn't able to compile successfully my PHP4 because it says that there is no such 
command as apxs. How and where will i acquire this and how to install it?
Thanks and I hope you could help me regarding this.


-- 
Edit Bug report at: http://bugs.php.net/?id=11865&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 #11865 Updated: apxs: command not found

[zak]

ID: 11865
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Compile Problem
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Please read the installation documents more carefully.

Previous Comments:
---

[2001-07-04 02:11:13] [EMAIL PROTECTED]

I wasn't able to compile successfully my PHP4 because it says that there is no such 
command as apxs. How and where will i acquire this and how to install it?
Thanks and I hope you could help me regarding this.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11865&edit=2


-- 
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 #11636 Updated: udm_set_agent_param($agent,UDM_PARAM_PAGE_NUM,$num) Doesn't set the active page

[gluke]

ID: 11636
Updated by: gluke
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Unknown/Other Function
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

It is not the bug.

You should call Udm_Free_Res and then Udm_Find again to get other pages. Or you can 
set a big number at UDM_PARAM_PAGE_NUM before Udm_Find for example.

The search is very highly optimized to get only UDM_PARAM_PAGE_NUM results.

Previous Comments:
---

[2001-06-23 22:25:42] [EMAIL PROTECTED]

After calling udm_find( $agent,"search string") ;

I can loop through the first 20 results (page size=20).
Then after that I cannot set the page using

udm_set_agent_param($agent,UDM_PARAM_PAGE_NUM,$num) 

It keeps returning the same page results (ie: 1-20).


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11636&edit=2


-- 
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]