Re: [PHP-DEV] Patch: Some undocumented php.ini directives

2003-03-22 Thread Michael Bretterklieber
Hi,

Joey Smith wrote:
Michael:

  Thanks for speaking up! I'd be glad to document this with your help. I
have a few questions.
	1) What is the format when this param is set to on?
its a weird format, sometimes I had the date-parts separated with spaces 
and the time without seconds, I guess it depends on some language 
settings, or the language of the installed windows.

2) This parameter doesn't appear to have any effect on the way
FreeTDS returns dates from MSSQL. Can you confirm/deny that?
it also works if you have compiled the MSSQL extension against FreeTDS, 
but currently there is a bug in the MSSQL extension when FreeTDS is 
compiled for the sybase-ctlib (wich is the default), wich causes a wrong 
month­-value because the sybase-lib returns the month starting with 0 
and the mssql-dblib with 1 (I submited already a patch for that to Frank 
M. Kromann).

But I don't know the standard format of FreeTDS when converting 
datetime-values.

However, I also saw a lot of bug-reports related this problem (weird 
datetime-values), it would be good to write in the docu, that this 
switch is a workaround for that problem.

bye,
--
--- -
Michael Bretterklieber- [EMAIL PROTECTED]
JAWA Management Software GmbH - http://www.jawa.at
Liebenauer Hauptstr. 200-- privat ---
A-8041 GRAZ GSM: ++43-(0)676-93 96 698
Tel: ++43-(0)316-403274-12  E-mail:   [EMAIL PROTECTED]
Fax: ++43-(0)316-403274-10  http://www.bretterklieber.com
--- -
...the number of UNIX installations has grown to 10, with more
expected... - Dennis Ritchie and Ken Thompson, June 1972
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] pecl binaries in PHP Win releases?

2003-04-03 Thread Michael Bretterklieber
Hi,

Jani Taskinen schrieb:
On 3 Apr 2003, Christian Stocker wrote:


As it's quite hard/expensive for Windows users to compile their own
extensions, is there a possibility to add some PECL-extensions into the
Windows releases? Mainly there are ext/radius and ext/imagick, which I
know do compile on Windows (and wouldn't add that much to the download,
since ext/imagick for example does not statically compile the whole
imagemagick libraries)
Would be great, if someone could add them to the windows compile scripts
on snaps.php.net.


Why not make a separate package of the extra extensions..?

in general its a good idea, but I'm thinking about how 
Webspace-Providers are installing and maintaining PHP, everything what 
is not in the standard distribution doesen't exist for them.
It's already a problem to convince them installing additional standard 
extensions or PEAR.

One possibility would be to move nearly (some extensions should stay in 
the PHP-dist like DB-extensions) all extensions to this extra package, 
then they have no chance to come around installing this extra package.

bye,
--
--- --
Michael Bretterklieber  - [EMAIL PROTECTED]	
JAWA Management Software GmbH   - http://www.jawa.at
Liebenauer Hauptstr. 200-- privat 
A-8041 GRAZ GSM: ++43-(0)676-84 03 15 712
Tel: ++43-(0)316-403274-12  E-mail: [EMAIL PROTECTED]
Fax: ++43-(0)316-403274-10  http://www.bretterklieber.com
--- --
...the number of UNIX installations has grown to 10, with more 
expected... - Dennis Ritchie and Ken Thompson, June 1972

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Re: 4.3.2RC4 OCI8 crash

2003-05-27 Thread Michael Bretterklieber
On Tue, 27 May 2003, Michael Mauch wrote:

 Michael Bretterklieber wrote:

  we discovered a crash using 4.3.2RC4 with oci8, here's the bt:

 Is your Apache linked to pthread, like it's written on
 http://www.php.net/oci8?
sure, and all other neat things like library-preload, etc.

we usualy start this script with the cli-php, but sometimes also from
apache.


 And your extension_dir .../no-debug-non-zts-20020429
 is probably the wrong one, as you are using --enable-debug.

we don't load any extensions dynamicaly (all exts are staticaly
compiled in) and usualy we use a non debug-build :-)

however we could workaround this, we had a function like this:

function foo()
{
$db = new DB;
$db-query(..)
..
}

this function was invoked several times, and our database-objects
connected also several times to oracle, then I declared $db static:
function foo()
{
static $db;
$db = new DB;
$db-query(..)
..
}

et voila, the script didn't crashed anymore :-)

It looks like that the oci extension has some bugs in freeing resources,
because according to the bt, the oci module freees an already freeed
resource, if I'm right, or maybe a problem with the reference counting,
...

tomorrow I can send the output with ociinternaldebug(true)

another hint, I tried all php versions down to 4.2.1, and all versions
caused the script to crash.

bye,
--
--- --
Michael Bretterklieber  - http://www.bretterklieber.com
JAWA Management Software GmbH   - http://www.jawa.at
Tel: ++43-(0)316-403274-12  - GSM: ++43-(0)676-84 03 15 712
--- --
...the number of UNIX installations has grown to 10, with more
expected... - Dennis Ritchie and Ken Thompson, June 1972

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] 4.3.2RC4 OCI8 crash

2003-05-28 Thread Michael Bretterklieber
Hi,

here's the output with ociinternaldebug(1):
http://www.bretterklieber.com/php/oci8_crash.log

FYI: the file has about 800KB

On Tue, 27 May 2003, Michael Bretterklieber wrote:
 Hi,

 we discovered a crash using 4.3.2RC4 with oci8, here's the bt:
 (gdb) bt
 #0  0x404422b4 in kghalp () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #1  0x4044fd28 in kgebem () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #2  0x404513de in kgedes () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #3  0x401851ff in skgudmp () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #4  0x4044e1bc in kgesiv () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #5  0x4044dfb8 in kgesic1 () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #6  0x4043d55a in kgherror () from
 /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #7  0x4044385f in kghfre () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #8  0x400f7332 in kpuhhfre () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #9  0x40101e1f in kpufhndl () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #10 0x40130b67 in OCIHandleFree () from /opt/oracle/OraHome1/lib/libclntsh.so.8.0
 #11 0x0809d2f5 in _oci_stmt_list_dtor (rsrc=0x8229554) at 
 /daten1/software/php-4.3.2RC4/ext/oci8/oci8.c:774
 #12 0x08166dce in list_entry_destructor (ptr=0x8ac1ff4) at 
 /daten1/software/php-4.3.2RC4/Zend/zend_list.c:172
 #13 0x08165546 in zend_hash_del_key_or_index (ht=0x81ef9a0, arKey=0x0, nKeyLength=0, 
 h=222, flag=1)
 at /daten1/software/php-4.3.2RC4/Zend/zend_hash.c:514
 #14 0x08166b45 in _zend_list_delete (id=222)
 at /daten1/software/php-4.3.2RC4/Zend/zend_list.c:56
 #15 0x0815fa4d in _zval_dtor (zvalue=0x8abff34)
 at /daten1/software/php-4.3.2RC4/Zend/zend_variables.c:69
 #16 0x08158b09 in _zval_ptr_dtor (zval_ptr=0x8abfc68)
 at /daten1/software/php-4.3.2RC4/Zend/zend_execute_API.c:291
 #17 0x08165659 in zend_hash_destroy (ht=0x8ac0394)
 at /daten1/software/php-4.3.2RC4/Zend/zend_hash.c:543
 #18 0x0815faab in _zval_dtor (zvalue=0xbfff1e10)
 at /daten1/software/php-4.3.2RC4/Zend/zend_variables.c:60
 #19 0x08172126 in zend_assign_to_variable (result=0x409b9018, op1=0x8abff14, 
 op2=0x409b9038, value=0x8ab9fa4, type=4, Ts=0xbfff1e60)
 at /daten1/software/php-4.3.2RC4/Zend/zend_execute.c:439
 #20 0x0816f2fa in execute (op_array=0x824d924)
 at /daten1/software/php-4.3.2RC4/Zend/zend_execute.c:1349
 #21 0x08161230 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
 at /daten1/software/php-4.3.2RC4/Zend/zend.c:869
 #22 0x08136eec in php_execute_script (primary_file=0xb570)
 at /daten1/software/php-4.3.2RC4/main/main.c:1671
 #23 0x08173d8f in main (argc=2, argv=0xb5f4)
 at /daten1/software/php-4.3.2RC4/sapi/cli/php_cli.c:802
 ---Type return to continue, or q return to quit---
 #24 0x408368ae in __libc_start_main () from /lib/libc.so.6


bye,
--
--- --
Michael Bretterklieber  - http://www.bretterklieber.com
JAWA Management Software GmbH   - http://www.jawa.at
Tel: ++43-(0)316-403274-12  - GSM: ++43-(0)676-84 03 15 712
--- --
...the number of UNIX installations has grown to 10, with more
expected... - Dennis Ritchie and Ken Thompson, June 1972

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] MySQL Problem retrieving errno, when connect fails + solution

2003-08-14 Thread Michael Bretterklieber
Hi,

There is a problem in the MySQL extension when trying to get the errno, if
the connection failed, if a prior mysql_connect() call already succeeded:

mysql_connect('host', 'user', 'pw');
mysql_connect('host2', 'user2', 'pw2');
echo mysql_errno();
echo mysql_error();

Assuming the first call succeeds, but the second fails, then mysql_errno()
just returns 0, but it shouldn't.

That's because mysql_errno() uses the default_link for getting the errno
in this case.

There are two possible solutions:
1. set the default_link to -1 before makeing a new connection
2. change mysql_errno, with something like:
... snip ...
case 1:
if (zend_get_parameters_ex(1, mysql_link)==FAILURE) {
if (MySG(connect_errno)!=0){
RETURN_LONG(MySG(connect_errno));
} else {
RETURN_FALSE;
}
}
id = -1;
break;
...

I think 1. would be the better solution because 2. is only a workaround,
or not?

thanx,
bye,
--
--- --
Michael Bretterklieber  - http://www.bretterklieber.com
JAWA Management Software GmbH   - http://www.jawa.at
Tel: ++43-(0)316-403274-12  - GSM: ++43-(0)676-84 03 15 712
--- --
...the number of UNIX installations has grown to 10, with more
expected... - Dennis Ritchie and Ken Thompson, June 1972

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php