Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at http://bugs.php.net/bug.php?id=48507&edit=1
ID: 48507
Comment by: pahan at hubbitus dot spb dot su
Reported by: krynble at yahoo dot com dot br
Summary: fgetcsv() ignoring special characters
Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Unix
PHP Version: 5.*
New Comment:
> Quote from the docs:
> Note: Locale setting is taken into account by this function. If LANG
is e.g.
> en_US.UTF-8, files in one-byte encoding are read wrong by this
function.
Ok, bug documented as "are read wrong by this function" is better then
nothing.
But do you plan fix this wrong behaviour?
Previous Comments:
[2010-05-18 11:03:42] m...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Quote from the docs:
Note: Locale setting is taken into account by this function. If LANG is
e.g. en_US.UTF-8, files in one-byte encoding are read wrong by this
function.
[2009-12-12 11:40:29] pahan at hubbitus dot spb dot su
Sorry for duplicate (#50456 is my), but in it, additionally to there
described problem in fgetcsv I also suggest fix fputcvs to allow [force]
enclosing single words in field.
Off course it does *not* solve this problem of incorrect fgetcsv
parsing, because RFC allow not quoted values (
http://www.faqs.org/rfcs/rfc4180.html , section 2.5 ), but, it is make
pair fputcsv/fgetcsv as minimum compatible in PHP implementation.
[2009-12-12 01:33:51] j...@php.net
See also bug #50456
[2009-09-22 15:09:20] phofstetter at sensational dot ch
below you'll find a small script which shows how to implement a user
filter that can be used to on-the-fly utf8-encode the data so that
fgetcsv is happy and returns correct output even if the first character
in a field has its high-bit set and is not valid utf-8:
Remember: This is a workaround and impacts performance. This is not a
valid fix for the bug.
I didn't yet have time to deeply look into the C implementation for
fgetcsv, but all these calls to php_mblen() feel suspicious to me.
I'll try and have a look into this later today, but for now, I'm just
glad I have this workaround (quickly hacked together - keep that in
mind):
is_utf8($bucket->data))
$bucket->data = utf8_encode($bucket->data);
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register("utf8encode", "utf8encode_filter")
or die("Failed to register filter");
$fp = fopen($_SERVER['argv'][1], "r");
/* Attach the registered filter to the stream just opened */
stream_filter_prepend($fp, "utf8encode");
while($data = fgetcsv($fp, 0, ';', '"'))
print_r($data);
fclose($fp);
[2009-09-22 14:45:22] phofstetter at sensational dot ch
I was looking into this (after having been bitten by it) and I can add
another tidbit that might help tracking this down:
The bug doesn't happen if the file fgetcsv() is reading is in
UTF-8-format.
I have created a test-file in ISO-8859-1 and then used
file_put_contents(utf8encode(file_get_contents())) to create the
UTF8-version of it (explaining this here because I'm not sure whether
this would write a BOM or not - probably not though).
That version could be read correctly.
I'm now writing a stream filter that does the UTF-8 conversion on the
fly to hook that in between the file and fgetcsv() - while I would lose
a bit of performance, in my case, this is the cleanest workaround.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=48507
--
Edit this bug report at http://bugs.php.net/bug.php?id=48507&edit=1
#48507 [Com]: fgetcsv() ignoring special characters
ID: 48507
Comment by: pahan at hubbitus dot spb dot su
Reported By: krynble at yahoo dot com dot br
Status: Verified
Bug Type: Filesystem function related
Operating System: Unix
PHP Version: 5.*
New Comment:
Sorry for duplicate (#50456 is my), but in it, additionally to there
described problem in fgetcsv I also suggest fix fputcvs to allow [force]
enclosing single words in field.
Off course it does *not* solve this problem of incorrect fgetcsv
parsing, because RFC allow not quoted values (
http://www.faqs.org/rfcs/rfc4180.html , section 2.5 ), but, it is make
pair fputcsv/fgetcsv as minimum compatible in PHP implementation.
Previous Comments:
[2009-12-12 01:33:51] j...@php.net
See also bug #50456
[2009-09-22 15:09:20] phofstetter at sensational dot ch
below you'll find a small script which shows how to implement a user
filter that can be used to on-the-fly utf8-encode the data so that
fgetcsv is happy and returns correct output even if the first character
in a field has its high-bit set and is not valid utf-8:
Remember: This is a workaround and impacts performance. This is not a
valid fix for the bug.
I didn't yet have time to deeply look into the C implementation for
fgetcsv, but all these calls to php_mblen() feel suspicious to me.
I'll try and have a look into this later today, but for now, I'm just
glad I have this workaround (quickly hacked together - keep that in
mind):
is_utf8($bucket->data))
$bucket->data = utf8_encode($bucket->data);
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register("utf8encode", "utf8encode_filter")
or die("Failed to register filter");
$fp = fopen($_SERVER['argv'][1], "r");
/* Attach the registered filter to the stream just opened */
stream_filter_prepend($fp, "utf8encode");
while($data = fgetcsv($fp, 0, ';', '"'))
print_r($data);
fclose($fp);
[2009-09-22 14:45:22] phofstetter at sensational dot ch
I was looking into this (after having been bitten by it) and I can add
another tidbit that might help tracking this down:
The bug doesn't happen if the file fgetcsv() is reading is in
UTF-8-format.
I have created a test-file in ISO-8859-1 and then used
file_put_contents(utf8encode(file_get_contents())) to create the
UTF8-version of it (explaining this here because I'm not sure whether
this would write a BOM or not - probably not though).
That version could be read correctly.
I'm now writing a stream filter that does the UTF-8 conversion on the
fly to hook that in between the file and fgetcsv() - while I would lose
a bit of performance, in my case, this is the cleanest workaround.
[2009-09-21 18:11:47] dmulryan at calendarwiz dot com
Note: Previous comment has error where URL is shown in array element.
This is not a bug but my error in the example. Bug is in special
characters.
[2009-09-21 18:07:42] dmulryan at calendarwiz dot com
Similar problem when parsing the following line:
0909211132,1,ØÊááàÑ,äÆæç,CForm,Y,1,1,1,97.95.176.240,2530
which produces empty array elements for fields with special
characters:
Array ( [0] => 0909211132 [1] => 1 [2] => [3] => [4] => URL [5] => Y
[6] => 1 [7] => 1 [8] => 1 [9] => 97.95.176.240 [10] => 2530 )
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48507
--
Edit this bug report at http://bugs.php.net/?id=48507&edit=1
#50456 [NEW]: fgetcsv is not binary-safe in different locales
From: pahan at hubbitus dot spb dot su
Operating system: Linux
PHP version: 5.3.1
PHP Bug Type: Filesystem function related
Bug description: fgetcsv is not binary-safe in different locales
Description:
If in unicode locale we construct CSV-file by fputcsv some values, such as
single words does not enclosed (even if enclosing character was directly
provided). Because that, in different locale file can't be parsed properly.
Be aware, I seen note in documentation, but I speak about binary-safe
parsing, do not interpret any symbols.
In followed example we get result csv-string:
Test;ÂÕáâ;"´ÒÐ áÛÞÒÐ"
Single wod is not enclosed. And I do not seen parameter to force enclosing
it. But, it can completely solve problem! So, csv-string:
"Test";"ÂÕáâ";"´ÒÐ áÛÞÒÐ"
correctly parsed in any locale (I repeat, I do not speak about further
symbol interpretation)!
So, as easy fix, which also should not produce any backward capability
problem my suggestion is add parameter to fputcsv to force enclosing
fields, even if it consist from 1 word. Or, may be even do this as default
behavior.
Reproduce code:
---
Expected result:
Test;ÂÕáâ;"´ÒÐ áÛÞÒÐ"
array(3) {
[0]=>
string(4) "Test"
[1]=>
string(8) "ÂÕáâ"
[2]=>
string(17) "´ÒÐ áÛÞÒÐ"
}
array(3) {
[0]=>
string(4) "Test"
[1]=>
string(0) "ÂÕáâ"
[2]=>
string(17) "´ÒÐ áÛÞÒÐ"
}
Actual result:
--
Test;ÂÕáâ;"´ÒÐ áÛÞÒÐ"
array(3) {
[0]=>
string(4) "Test"
[1]=>
string(8) "ÂÕáâ"
[2]=>
string(17) "´ÒÐ áÛÞÒÐ"
}
array(3) {
[0]=>
string(4) "Test"
[1]=>
string(0) ""
[2]=>
string(17) "´ÒÐ áÛÞÒÐ"
}
--
Edit bug report at http://bugs.php.net/?id=50456&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50456&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50456&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50456&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50456&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50456&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50456&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50456&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50456&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50456&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50456&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50456&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50456&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50456&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50456&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50456&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50456&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50456&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50456&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50456&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50456&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50456&r=mysqlcfg
#47520 [Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
Problem in pcre library is a problem of pcre library.
BUT segmentation fault of PHP is a bug PHP itself in any case!!!
I can understand what it may be very hard to fix, but completely do not
understand why you mark it as Bogus!
Previous Comments:
[2009-03-03 01:40:03] il...@php.net
There is not much we can do about recursion limits other then suggest
the lowering of the pcre.recursion_limit setting. The basic problem is
that PCRE library (not PHP) is eating up the system stack during
recursion and subsequently crashes when it runs out of room.
This is not a PHP bug.
[2009-03-02 10:09:28] phpwnd at gmail dot com
I forgot to add that in my case, lowering the value the
pcre.recursion_limit INI setting make preg_* functions fail instead of
making PHP segfault.
[2009-03-02 10:01:52] phpwnd at gmail dot com
I'd like to add that you don't need such a complicated test case, you
can make preg_* segfault with just something like:
$str = str_repeat(' ', 2490);
preg_match('#(.)+#', $str);
On my computer, a 2490-chars string is long enough to make it segfaults
everytime. For some reason, 2489 chars will make it segfault only 1 out
of 5 runs and 2480 chars are perfectly fine. If I replace the regexp
with more capturing parenthesis such as #((.))+# that limit drops to
1500-or-so and that number decreases as the number of parenthesis
increases. Using non-capturing patterns such as #(?:.)+# doubles that
number.
Obviously, the bug is related to capturing patterns repetition,
assuming we're experiencing the same bug. I'll try to find a place where
to host a core dump.
--------
[2009-02-28 09:00:02] pahan at hubbitus dot spb dot su
Very apologize for mistake.
I'm fix rights now, please recheck.
[2009-02-28 01:19:21] fel...@php.net
I cannot download the coredump file: "You don't have permission to
access /_temp/php-pcre-bug/2/core.10135 on this server."
Can you give us a backtrace?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47520
--
Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47520 [Fbk->Opn]: PHP segfaulted in preg_replace on processing long string
ID: 47520
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
Very apologize for mistake.
I'm fix rights now, please recheck.
Previous Comments:
[2009-02-28 01:19:21] fel...@php.net
I cannot download the coredump file: "You don't have permission to
access /_temp/php-pcre-bug/2/core.10135 on this server."
Can you give us a backtrace?
[2009-02-27 20:06:13] pahan at hubbitus dot spb dot su
I'm thrice check the previous reports about this issue. And what? All
closed as bogus, but segmentatoin fault still here! Where
solution/fix??? Even common workaraund of problem is absent.
Why it is bogus but not bug???
And also, please again read note: I use "Once-only subpattern", so,
this should prevent recursion as I can understand. Or not?
[2009-02-27 19:37:00] fel...@php.net
Please, check the previous reports about this issue:
http://bugs.php.net/search.php?search_for=&boolean=1&limit=10&order_by=id&direction=DESC&cmd=display&status=Bogus&bug_type%5B%5D=PCRE+related&php_os=&phpver=&assign=&author_email=&bug_age=0
http://docs.php.net/manual/en/pcre.configuration.php
------------------------
[2009-02-27 11:13:58] pahan at hubbitus dot spb dot su
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?>(?:[^']|(?<=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file
named test.php):
for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by
length of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (?> ... ) to speedup and
dissallow recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 ,
http://bugs.php.net/bug.php?id=47376 ,
http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
//1: Always "segmantation
fault"
//$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in
1000 iterations) "segmantation fault"
//$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50%
$reg = "#'((?>(?:[^']|(?<=\\\)')*))'#";
preg_replace($reg, '', $cont);
echo "OK\n";
?>
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47520 [Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
I'm thrice check the previous reports about this issue. And what? All
closed as bogus, but segmentatoin fault still here! Where
solution/fix??? Even common workaraund of problem is absent.
Why it is bogus but not bug???
And also, please again read note: I use "Once-only subpattern", so,
this should prevent recursion as I can understand. Or not?
Previous Comments:
[2009-02-27 19:37:00] fel...@php.net
Please, check the previous reports about this issue:
http://bugs.php.net/search.php?search_for=&boolean=1&limit=10&order_by=id&direction=DESC&cmd=display&status=Bogus&bug_type%5B%5D=PCRE+related&php_os=&phpver=&assign=&author_email=&bug_age=0
http://docs.php.net/manual/en/pcre.configuration.php
------------------------
[2009-02-27 11:13:58] pahan at hubbitus dot spb dot su
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?>(?:[^']|(?<=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file
named test.php):
for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by
length of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (?> ... ) to speedup and
dissallow recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 ,
http://bugs.php.net/bug.php?id=47376 ,
http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
//1: Always "segmantation
fault"
//$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in
1000 iterations) "segmantation fault"
//$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50%
$reg = "#'((?>(?:[^']|(?<=\\\)')*))'#";
preg_replace($reg, '', $cont);
echo "OK\n";
?>
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47520 [NEW]: PHP segfaulted in preg_replace on processing long string
From: pahan at hubbitus dot spb dot su
Operating system: Linux
PHP version: 5.3.0beta1
PHP Bug Type: PCRE related
Bug description: PHP segfaulted in preg_replace on processing long string
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?>(?:[^']|(?<=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file named
test.php):
for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by length
of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (?> ... ) to speedup and dissallow
recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 , http://bugs.php.net/bug.php?id=47376
, http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
//1: Always "segmantation fault"
//$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in 1000
iterations) "segmantation fault"
//$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50%
$reg = "#'((?>(?:[^']|(?<=\\\)')*))'#";
preg_replace($reg, '', $cont);
echo "OK\n";
?>
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=47520&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47520&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47520&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47520&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47520&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47520&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47520&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47520&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47520&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47520&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47520&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47520&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47520&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47520&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47520&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47520&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47520&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47520&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47520&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47520&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47520&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47520&r=mysqlcfg
#47376 [Bgs]: Segmentation fault in preg_replace on many repitition of pattern
ID: 47376
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
>Your pattern could be: /(@@ -[\d,]+ \+[\d,]+ @@\s)(?1)+/
Yes, it seems as workaround (for my current work I apply other
workaraund too). It has not similar stack problems?
Wuote from info by you link:
Unfortunately, the effect of running out of stack is often
SIGSEGV,
though sometimes a more explicit error message is given. You
can nor-
mally increase the limit on stack size by code such as this:
struct rlimit rlim;
getrlimit(RLIMIT_STACK, &rlim);
rlim.rlim_cur = 100*1024*1024;
setrlimit(RLIMIT_STACK, &rlim);
So, main question is - may you correctly handle this problem at all
(throw/catch exceptions, fire errors, warnings etc.)??
For example, code such:
echo preg_replace('/(@@ -[\d,]+ \+[\d,]+ @@\s){2,643}/s', '-some
data-', $text);
generate warning:
PHP Warning: preg_replace(): Compilation failed: regular expression is
too large at offset 33 in /home/pasha/pcre-php-bug/pcre_bug.php on line
14
and all ok - I can correctly handle this situation on my script.
In any case, on production server segmentation fault depended from
incoming data is very-very bad idea.
Previous Comments:
[2009-02-13 10:10:45] fel...@php.net
It's a known PCRE issue, and is documented:
http://www.manpagez.com/man/3/pcrestack/
[2009-02-13 10:01:29] fel...@php.net
Your pattern could be: /(@@ -[\d,]+ \+[\d,]+ @@\s)(?1)+/
--------
[2009-02-13 09:01:51] pahan at hubbitus dot spb dot su
Thank you for the links it was pretty usefully.
I'm read information on it. Very strange read PHP documentation like:
QUOTE:http://ru.php.net/manual/en/pcre.configuration.php
pcre.recursion_limit integer
PCRE's recursion limit. Please note that if you set this value to a
*high number you may consume all the available process stack and
eventually crash PHP* (due to reaching the stack size limit imposed by
the Operating System).
/QUOTE
Really you can't provide any runtime check and provide standard way to
handle errors (or warnings)???
So, this low level limitation may be in pcre, but crash of PHP is PHP
BUG in any case!
And, If you a interesting, I'm make more investigation on this theme:
On default OS limit:
$ ulimit -s
10240
example script behaves as:
//ini_set('pcre.recursion_limit', 9939);//Segmentation fault
//ini_set('pcre.recursion_limit', 9938);//Work
So, If I increase stack size on my system:
$ ulimit -s 65536
all work fine, as expected!!!
[2009-02-13 00:53:14] fel...@php.net
It isn't a PHP bug.
See bug#33468, bug#39387.
Thanks.
------------------------
[2009-02-12 22:51:08] pahan at hubbitus dot spb dot su
Sorry, sorry. Off course line "$text = file();" in reproduce code
unnecessary. Please remove it.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47376
--
Edit this bug report at http://bugs.php.net/?id=47376&edit=1
#47376 [Bgs]: Segmentation fault in preg_replace on many repitition of pattern
ID: 47376
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
Thank you for the links it was pretty usefully.
I'm read information on it. Very strange read PHP documentation like:
QUOTE:http://ru.php.net/manual/en/pcre.configuration.php
pcre.recursion_limit integer
PCRE's recursion limit. Please note that if you set this value to a
*high number you may consume all the available process stack and
eventually crash PHP* (due to reaching the stack size limit imposed by
the Operating System).
/QUOTE
Really you can't provide any runtime check and provide standard way to
handle errors (or warnings)???
So, this low level limitation may be in pcre, but crash of PHP is PHP
BUG in any case!
And, If you a interesting, I'm make more investigation on this theme:
On default OS limit:
$ ulimit -s
10240
example script behaves as:
//ini_set('pcre.recursion_limit', 9939);//Segmentation fault
//ini_set('pcre.recursion_limit', 9938);//Work
So, If I increase stack size on my system:
$ ulimit -s 65536
all work fine, as expected!!!
Previous Comments:
[2009-02-13 00:53:14] fel...@php.net
It isn't a PHP bug.
See bug#33468, bug#39387.
Thanks.
------------
[2009-02-12 22:51:08] pahan at hubbitus dot spb dot su
Sorry, sorry. Off course line "$text = file();" in reproduce code
unnecessary. Please remove it.
--------------------
[2009-02-12 22:12:28] pahan at hubbitus dot spb dot su
Description:
On text, where search pattern repeated many times (>643 times by test)
php segfaulted (Core dump you may download here:
http://ru.bir.ru/_temp/php-pcre-bug/core.8729 ) on preg_replace.
So, if we reduce length of test text (
http://ru.bir.ru/_temp/php-pcre-bug/pcre_bug.text ) on 1 line, or just
limit repetition on 1 - it is worked.
All Zend-modules was disabled.
Reproduce code:
---
Expected result:
Work as when text is less.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47376&edit=1
#47376 [Com]: Segmentation fault in preg_replace on many repitition of pattern
ID: 47376 Comment by: pahan at hubbitus dot spb dot su Reported By: pahan at hubbitus dot spb dot su Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.3.0beta1 New Comment: Sorry, sorry. Off course line "$text = file();" in reproduce code unnecessary. Please remove it. Previous Comments: [2009-02-12 22:12:28] pahan at hubbitus dot spb dot su Description: On text, where search pattern repeated many times (>643 times by test) php segfaulted (Core dump you may download here: http://ru.bir.ru/_temp/php-pcre-bug/core.8729 ) on preg_replace. So, if we reduce length of test text ( http://ru.bir.ru/_temp/php-pcre-bug/pcre_bug.text ) on 1 line, or just limit repetition on 1 - it is worked. All Zend-modules was disabled. Reproduce code: --- Expected result: Work as when text is less. Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=47376&edit=1
#47376 [NEW]: Segmentation fault in preg_replace on many repitition of pattern
From: pahan at hubbitus dot spb dot su Operating system: Linux PHP version: 5.3.0beta1 PHP Bug Type: PCRE related Bug description: Segmentation fault in preg_replace on many repitition of pattern Description: On text, where search pattern repeated many times (>643 times by test) php segfaulted (Core dump you may download here: http://ru.bir.ru/_temp/php-pcre-bug/core.8729 ) on preg_replace. So, if we reduce length of test text ( http://ru.bir.ru/_temp/php-pcre-bug/pcre_bug.text ) on 1 line, or just limit repetition on 1 - it is worked. All Zend-modules was disabled. Reproduce code: --- Expected result: Work as when text is less. Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=47376&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47376&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47376&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47376&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47376&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47376&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47376&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47376&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47376&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47376&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47376&r=support Expected behavior: http://bugs.php.net/fix.php?id=47376&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47376&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47376&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47376&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47376&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47376&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47376&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47376&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47376&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47376&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47376&r=mysqlcfg
#45336 [Com]: Compile breaks on Generating phar.phar
ID: 45336 Comment by: pahan at hubbitus dot spb dot su Reported By: pahan at hubbitus dot spb dot su Status: Feedback Bug Type: *Compile Issues Operating System: Linux PHP Version: 5.3CVS-2008-06-23 (snap) New Comment: I'm build snapshot 200806291230. Now all seems Ok. Very thanks. Previous Comments: [2008-06-28 00:51:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-06-23 15:02:10] pahan at hubbitus dot spb dot su Description: Compilation breaks on Generating phar.phar after generate of phar.php. Last few strings of output are: /bin/sh /usr/src/redhat/BUILD/php5.3-200806231230/build-cgi/libtool --silent --preserve-dup-deps --mode=install c p ext/zip/zip.la /usr/src/redhat/BUILD/php5.3-200806231230/build-cgi/modules Generating phar.php Generating phar.phar Unknown parameter '-f' to command pack, check ext/phar/phar.php help make: *** [ext/phar/phar.phar] Error 1 Reproduce code: --- configure make :) I anticipate that it is not depend of configure options, if --disable-phar not present. Expected result: Compile successfully. Actual result: -- Last error comes from command: /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php pack -f ext/phar/phar.phar -a pharcommand -c auto -x CVS -p 0 -s /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/phar.php -h sha1 -b /usr/bin/php /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/ So, check help: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php help pack pack Pack files into a PHAR archive. When using -s , then the stub file is being excluded from the list of input files/dirs.To create an archive that contains PEAR class PHP_Archiave then point -p argument to PHP/Archive.php. Required arguments: -F Specifies the phar file to work on. ... Any number of input files and directories. If -i is in use then ONLY files and matching thegiven regular expression are being packed. If -x is given then files matching that regular expression are NOT being packed. Ok, try -F instead of -f, get another error: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php pack -F ext/phar/phar.phar -a pharcommand -c auto -x CVS -p 0 -s /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/phar.php -h sha1 -b /usr/bin/php /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/ Unknown parameter '-a' to command pack, check ext/phar/phar.php help Removing -a, and other parameters, which are unknown do not give result. It seems as make-command from Phar 2.0 on old Phar extension 1.49.2.8. Furthermore, it seems as old phar.php in new phar 2.0: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php version PHP Version: 5.3.0-dev phar.phar version: $Revision: 1.49.2.8 $ Phar EXT version: 2.0.0b2-dev Phar API version: 1.1.1 Phar-based phar archives: enabled Tar-based phar archives: enabled ZIP-based phar archives: enabled gzip compression: enabled bzip2 compression: enabled supported signatures: MD5, SHA-1, SHA-256, SHA-512, OpenSSL -- Edit this bug report at http://bugs.php.net/?id=45336&edit=1
#44376 [Com]: MBstring extension load failed
ID: 44376 Comment by: pahan at hubbitus dot spb dot su Reported By: petr at hroch dot info Status: No Feedback Bug Type: mbstring related Operating System: Linux Debian Etch 4.0 PHP Version: 5.3CVS-2008-03-08 (snap) New Comment: Build snapshot 200806231230 - have same error while load mbstring module: bash-3.2$ php -v PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/mbstring.so' - /usr/lib/php/modules/mbstring.so: undefined symbol: second_arg_force_ref in Unknown on line 0 PHP 5.3.0-dev (cli) (built: Jun 23 2008 22:25:28) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies with Xdebug v2.1.0-dev, Copyright (c) 2002-2008, by Derick Rethans Previous Comments: [2008-03-17 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-03-09 22:47:40] [EMAIL PROTECTED] Keeping the state on "Feedback" till there was feedback :-) [2008-03-09 21:40:19] petr at hroch dot info Ok. I'll recheck it on Monday morning and let you know. Regards Petr [2008-03-08 22:15:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi looks like you're using an extension from another PHP version or similar. Please check that you're not mixing different versions... [2008-03-08 19:20:07] [EMAIL PROTECTED] Works fine here... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44376 -- Edit this bug report at http://bugs.php.net/?id=44376&edit=1
#45336 [NEW]: Compile breaks on Generating phar.phar
From: pahan at hubbitus dot spb dot su Operating system: Linux PHP version: 5.3CVS-2008-06-23 (snap) PHP Bug Type: *Compile Issues Bug description: Compile breaks on Generating phar.phar Description: Compilation breaks on Generating phar.phar after generate of phar.php. Last few strings of output are: /bin/sh /usr/src/redhat/BUILD/php5.3-200806231230/build-cgi/libtool --silent --preserve-dup-deps --mode=install c p ext/zip/zip.la /usr/src/redhat/BUILD/php5.3-200806231230/build-cgi/modules Generating phar.php Generating phar.phar Unknown parameter '-f' to command pack, check ext/phar/phar.php help make: *** [ext/phar/phar.phar] Error 1 Reproduce code: --- configure make :) I anticipate that it is not depend of configure options, if --disable-phar not present. Expected result: Compile successfully. Actual result: -- Last error comes from command: /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php pack -f ext/phar/phar.phar -a pharcommand -c auto -x CVS -p 0 -s /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/phar.php -h sha1 -b /usr/bin/php /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/ So, check help: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php help pack pack Pack files into a PHAR archive. When using -s , then the stub file is being excluded from the list of input files/dirs.To create an archive that contains PEAR class PHP_Archiave then point -p argument to PHP/Archive.php. Required arguments: -F Specifies the phar file to work on. ... Any number of input files and directories. If -i is in use then ONLY files and matching thegiven regular expression are being packed. If -x is given then files matching that regular expression are NOT being packed. Ok, try -F instead of -f, get another error: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php pack -F ext/phar/phar.phar -a pharcommand -c auto -x CVS -p 0 -s /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/phar.php -h sha1 -b /usr/bin/php /usr/src/redhat/BUILD/php5.3-200806230630/ext/phar/phar/ Unknown parameter '-a' to command pack, check ext/phar/phar.php help Removing -a, and other parameters, which are unknown do not give result. It seems as make-command from Phar 2.0 on old Phar extension 1.49.2.8. Furthermore, it seems as old phar.php in new phar 2.0: bash-3.2$ /usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/sapi/cli/php -n -d extension_dir=/usr/src/redhat/BUILD/php5.3-200806230630/build-cgi/modules -d open_basedir= -d output_buffering=0 -d memory_limit=-1 -d phar.readonly=0 ext/phar/phar.php version PHP Version: 5.3.0-dev phar.phar version: $Revision: 1.49.2.8 $ Phar EXT version: 2.0.0b2-dev Phar API version: 1.1.1 Phar-based phar archives: enabled Tar-based phar archives: enabled ZIP-based phar archives: enabled gzip compression: enabled bzip2 compression: enabled supported signatures: MD5, SHA-1, SHA-256, SHA-512, OpenSSL -- Edit bug report at http://bugs.php.net/?id=45336&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45336&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45336&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45336&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45336&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45336&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45336&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45336&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45336&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45336&r=support Expected behavior:http://bugs.php.net/fix.php?id=45336&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45336&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45336&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45336&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45336&r=p
#18833 [Com]: exec() : After throusands calls, causes "Unable to fork" error
ID: 18833
Comment by: pahan at hubbitus dot spb dot su
Reported By: antoine dot bajolet at tdf dot fr
Status: No Feedback
Bug Type: *General Issues
Operating System: GNU/Linux 2.4.9 RH 7.1
PHP Version: 4.2.1
New Comment:
Have same trouble in PHP snapshot 200805080630:
PHP Warning: exec(): Unable to fork [echo -ne '2008-06-01 05:15:27:
Login: Unable to login (User: [EMAIL PROTECTED]
y.ru)! reason:not connected! (CMD:LOGIN)
sleep 50 seconds
' >> /home/pasha/temp/php-IMAP/logs/log_ERR 2>&1] in
/var/www/_SHARED_/Debug/HuLOG.php on line 115
PHP Stack trace:
PHP 1. {main}() /home/pasha/temp/php-IMAP/IMAP_answer.php:0
PHP 2. IMAP_mailbox_change_answer()
/home/pasha/temp/php-IMAP/IMAP_answer.php:201
PHP 3. HuLOG->toLog() /home/pasha/temp/php-IMAP/IMAP_answer.php:67
PHP 4. HuLOG->writeLogs() /var/www/_SHARED_/Debug/HuLOG.php:158
PHP 5. HuLOG->log_to_file() /var/www/_SHARED_/Debug/HuLOG.php:162
PHP 6. exec() /var/www/_SHARED_/Debug/HuLOG.php:115
Warning: exec(): Unable to fork [echo -ne '2008-06-01 05:15:27: Login:
Unable to login (User: [EMAIL PROTECTED])
! reason:not connected! (CMD:LOGIN)
sleep 50 seconds
' >> /home/pasha/temp/php-IMAP/logs/log_ERR 2>&1] in
/var/www/_SHARED_/Debug/HuLOG.php on line 115
Call Stack:
0.0019 375364 1. {main}()
/home/pasha/temp/php-IMAP/IMAP_answer.php:0
184145.8861 16442044 2. IMAP_mailbox_change_answer()
/home/pasha/temp/php-IMAP/IMAP_answer.php:201
184145.8903 16451552 3. HuLOG->toLog()
/home/pasha/temp/php-IMAP/IMAP_answer.php:67
184145.8908 16451648 4. HuLOG->writeLogs()
/var/www/_SHARED_/Debug/HuLOG.php:158
184145.8908 16451648 5. HuLOG->log_to_file()
/var/www/_SHARED_/Debug/HuLOG.php:162
184145.8917 16451824 6. exec()
/var/www/_SHARED_/Debug/HuLOG.php:115
Previous Comments:
[2007-12-05 05:22:57] jinglerobs at yahoo dot com
Im using PHP 5.2.4 (cli), Apache & Mysql combination on a Slackware
box.
While running a script that processes large XML files and writes the
log to a log file, I get
Warning: exec(): Unable to fork
Initially the script runs fine for some 3 or 4 hours after which it
gives out the warnings. The script has a huge amount of data to process.
I also tried to use the nohup command but was of no use.
A screenshot of the problem is given below:
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13001','Microsoft','Windows XP
Home','0.0.0SP1','0','0','0','SP1','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec nohup setsid
echo \"DEBUG: INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13001','Microsoft','Windows XP
Home','0.0.0SP1','0','0','0','SP1','Software') \">>feed2vendorDB.log
2>&1 &"] in
/usr/local/apache2/htdocs/xml_feed/sircc_agnostic/feed2vendorDB/feed2vendorDB.php
on line 1454
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13002','Microsoft','Windows XP
Professional','0.0.0SP1','0','0','0','SP1','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec nohup setsid
echo \"DEBUG: INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13002','Microsoft','Windows XP
Professional','0.0.0SP1','0','0','0','SP1','Software')
\">>feed2vendorDB.log 2>&1 &"] in
/usr/local/apache2/htdocs/xml_feed/sircc_agnostic/feed2vendorDB/feed2vendorDB.php
on line 1454
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13134','KaZaA','KaZaA Media
Desktop','2.0.0','2','0','0','','Software')
Warning: exec(): Unable to fork [/usr/bin/bash -c "exec nohup setsid
echo \"DEBUG: INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('13134','KaZaA','KaZaA Media
Desktop','2.0.0','2','0','0','','Software') \">>feed2vendorDB.log 2>&1
&"] in
/usr/local/apache2/htdocs/xml_feed/sircc_agnostic/feed2vendorDB/feed2vendorDB.php
on line 1454
DEBUG:INSERT into package
(id,vendor,title,version,ver_major,ver_minor,ver_sub,ver_ext,type)
values ('11051','KaZaA','KaZa
#28356 [Com]: reading my.cnf
ID: 28356 Comment by: pahan at hubbitus dot spb dot su Reported By: takeshi at softagency dot co dot jp Status: Assigned Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.6 Assigned To: georg New Comment: >in particular, this breaks charset settings, which default to latin1 in lack of my.cnf. No, No, No! You may specify more than one default [client] group, to be able set to your taste settings of charsets and other settings. Previous Comments: [2007-06-19 13:00:44] foo at bar dot com in particular, this breaks charset settings, which default to latin1 in lack of my.cnf. [2006-05-18 23:30:43] nene_cz at yahoo dot co dot uk Hi, is there any progress in this feature request in php 4.x ? [2004-05-11 08:39:04] [EMAIL PROTECTED] feature request, assigning to georg. [2004-05-11 04:37:08] takeshi at softagency dot co dot jp Description: please add mysql_options(&mysql->conn, MYSQL_READ_DEFAULT_GROUP, "php"); before mysql_real_connect() This read /etc/my.cnf [php] group. -- Edit this bug report at http://bugs.php.net/?id=28356&edit=1
