#12556 [Csd->Opn]: fgetcsv ignores length if quotes not closed
ID: 12556
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 4.3.0-dev
New Comment:
I just tested this with php4-200212051430 and it still segfaults.
Previous Comments:
[2002-08-18 02:56:19] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-07-11 03:05:55] [EMAIL PROTECTED]
This example of yours actually crashes with current HEAD..
(gdb) bt
#0 0x4192fdc9 in memchr () from /lib/libc.so.6
#1 0x8559784 in ?? () at md4.c:255
#2 0x41922fa6 in _IO_getline (fp=0x855dd58, buf=0x8559784 "", n=23,
delim=10, extract_delim=1) at iogetline.c:39
#3 0x419227a0 in _IO_fgets (buf=0x8559784 "", n=24, fp=0x855dd58) at
iofgets.c:48
#4 0x82450bd in php_stdiop_gets (stream=0x855e894, buf=0x8559784 "",
size=24)
at /usr/src/web/php/php4/main/streams.c:696
#5 0x8243e34 in _php_stream_gets (stream=0x855e894, buf=0x8559784 "",
maxlen=24)
at /usr/src/web/php/php4/main/streams.c:248
#6 0x81cb335 in zif_fgetcsv (ht=2, return_value=0x855e2ac,
this_ptr=0x0, return_value_used=1)
at /usr/src/web/php/php4/ext/standard/file.c:2070
#7 0x82828b7 in execute (op_array=0x85596fc) at
/usr/src/web/php/php4/Zend/zend_execute.c:1587
#8 0x826fbc4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php4/Zend/zend.c:810
#9 0x8239951 in php_execute_script (primary_file=0xb95c) at
/usr/src/web/php/php4/main/main.c:1388
#10 0x8288e07 in main (argc=2, argv=0xb9c4) at
/usr/src/web/php/php4/sapi/cli/php_cli.c:674
#11 0x418e89cb in __libc_start_main (main=0x828829c , argc=2,
argv=0xb9c4, init=0x8086d78 <_init>,
fini=0x82fed04 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xb9bc)
at ../sysdeps/generic/libc-start.c:92
[2001-08-03 12:45:29] [EMAIL PROTECTED]
Ok, I can live with the embedded newlines in fgetcsv even though I
think it is wrong. No other app will read a csv file this way. MySQL
for example exports a literal \n for newlines and translates them on
import rather than embedding them.
But, I do think the length should be respected no matter what:
data:
-
6,7,8,line1
1,2,3,"line2
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
2,4,5,line3
script:
---
$fp=fopen("test.csv", "r");
while($line=fgetcsv($fp, 24)){
print_r($line);
}
Nothing after that quote gets read. Even after 24 bites have been
read.
It would seem to me that the code which reads an additional line if an
embedded newline is reached should not issue an FP_FGETS with len but
should use len-strlen(temp). This would make the length param make
more sense. And then if len was met it should terminate the record and
start all over.
The code in this function is less that understandable with all the
great names like buff and temp floating around. I tried looking at it
but will leave it to the guys who wrote it.
--
Edit this bug report at http://bugs.php.net/?id=12556&edit=1
#21294 [NEW]: register_shutdown_function output no compressed
From: [EMAIL PROTECTED] Operating system: Linux 2.4.18 PHP version: 4.3.0 PHP Bug Type: Output Control Bug description: register_shutdown_function output no compressed register_shutdown_function now allow output. However, this output is not compressed by zlib.output_compression. It must be sent after the output buffer is flushed. Mozilla will casually truncate the invalid parts. However, IE will unpredictably stop loading the page and will sometimes not load the page at all. In the below example, the output from the function shutdown_test will not be compressed. You can see the test for yourself at http://dev.phorum.org/zlibtest.php This is in the HTML body. To see the raw output, You can try: # wget -O - --header='Accept-Encoding: gzip' http://dev.phorum.org/zlibtest.php | less -- Edit bug report at http://bugs.php.net/?id=21294&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21294&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21294&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21294&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21294&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21294&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21294&r=support Expected behavior: http://bugs.php.net/fix.php?id=21294&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21294&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21294&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21294&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21294&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21294&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21294&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21294&r=gnused
#21304 [NEW]: gzopen does not open the file
From: [EMAIL PROTECTED] Operating system: Linux 2.4.18 PHP version: 4.3.0 PHP Bug Type: Zlib Related Bug description: gzopen does not open the file This was working fine with 4.2.3. Simple script, yes I should if $fp, but it is a test script. example: http://dev.phorum.org/gztest.php $fp is empty but there is no error from gzopen at all. I have all errors on. In fact, you do get a warning from gzwrite and gzclose that $fp is not valid stream. -- Edit bug report at http://bugs.php.net/?id=21304&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21304&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21304&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21304&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21304&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21304&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21304&r=support Expected behavior: http://bugs.php.net/fix.php?id=21304&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21304&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21304&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21304&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21304&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21304&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21304&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21304&r=gnused
#21304 [Opn]: gzopen does not open the file
ID: 21304 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zlib Related Operating System: Linux 2.4.18 PHP Version: 4.3.0 New Comment: FWIW, I just checked and only append is affected. If I open the file with "w", it works fine. Obviously, I need "a", but that should help. Previous Comments: [2002-12-31 01:40:02] [EMAIL PROTECTED] This was working fine with 4.2.3. Simple script, yes I should if $fp, but it is a test script. example: http://dev.phorum.org/gztest.php $fp is empty but there is no error from gzopen at all. I have all errors on. In fact, you do get a warning from gzwrite and gzclose that $fp is not valid stream. -- Edit this bug report at http://bugs.php.net/?id=21304&edit=1
#26665 [Bgs->Opn]: php crashes with large files and array work (2MB Script File). win32 works.
ID: 26665 Updated by: [EMAIL PROTECTED] Reported By: fschaper at intux dot org -Status: Bogus +Status: Open Bug Type: Reproducible crash Operating System: * PHP Version: 4CVS, 5CVS New Comment: I can reproduce this at will. It is not a memory issue as I can create the array in code with ease and not crash. I can also split the file into several files and all is ok. It is only when I try to load a large file (~2.8MB for me) that PHP crashes. I provide the following test file that is 4MB+ that crashes every time. http://spidey.dealnews.com/~brianm/php_large_file_crash.php.txt As you will see, I have an early call to exit() in that file. That nor the echo ever happens. I ran this with and without my custom php.ini file. My PHP version info: $ php -v PHP 4.3.4 (cli) (built: Feb 5 2004 16:00:45) (DEBUG) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies gdb did not give me much: (gdb) run Starting program: /usr/local/bin/php php_large_file_crash.php.txt Program received signal SIGSEGV, Segmentation fault. execute (op_array=0x8221834) at /usr/src/apache/php-4.3.4/Zend/zend_execute.c:1071 1071zend_clean_garbage(TSRMLS_C); We generate large amounts of cached arrays in files. This is the first time this has happened as far as I know. Previous Comments: [2003-12-30 10:26:38] [EMAIL PROTECTED] Does not crash for me. And the example script is pretty useless anyway, you really should be using error_reporting = E_ALL once.. [2003-12-22 07:59:26] fschaper at intux dot org This Bug can be repoduduced under Window's as well, only the file-size has to be larger (will depend on system memory etc.). I have tried it with an 8MB version (might as well take less than that) of the script (the one I added the link to) and PHP crashes under Windows as well. [2003-12-19 09:59:05] fschaper at intux dot org This time I ran the script via the shell without apache (gdb) bt #0 0x0811f8f6 in execute (op_array=0x819841c) at /usr/src/debug/php4-STABLE-200312191430/Zend/zend_execute.c:1758 #1 0x0810fa28 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/debug/php4-STABLE-200312191430/Zend/zend.c:884 #2 0x080ed1d3 in php_execute_script (primary_file=0xbcf8) at /usr/src/debug/php4-STABLE-200312191430/main/main.c:1729 #3 0x08125eb3 in main (argc=2, argv=0xbd74) at /usr/src/debug/php4-STABLE-200312191430/sapi/cgi/cgi_main.c:1578 (gdb) frame 0 #0 0x0811f8f6 in execute (op_array=0x819841c) at /usr/src/debug/php4-STABLE-200312191430/Zend/zend_execute.c:1758 1758ALLOC_ZVAL(valptr); [2003-12-19 04:36:10] fschaper at intux dot org Description: While working with "many" array's (around 2MB of code) we encountered a crash on linux-systems while everything works fine under windows. PHP silently fails - only error log is the apache segfault. Apache 1.3.28 PHP 4.3.3 Reproduce code: --- http://www.intux.org/tmp/php_segf_test.tar.gz 100 Lines of code works Around 103 lines and more and it starts to break down Expected result: The last PHP command should write an "done" on the page. Actual result: -- An empty document should be returned since apache simply crashes -- Edit this bug report at http://bugs.php.net/?id=26665&edit=1
Bug #52302 [Bgs->Opn]: mysqli_fetch_all does not work with MYSQLI_USE_RESULT
Edit report at http://bugs.php.net/bug.php?id=52302&edit=1 ID: 52302 Updated by: brianlm...@php.net Reported by: brianlm...@php.net Summary: mysqli_fetch_all does not work with MYSQLI_USE_RESULT -Status: Bogus +Status: Open Type: Bug Package: MySQLi related Operating System: Linux PHP Version: 5.3.2 Assigned To: mysql New Comment: No, it makes perfect sense. In fact, it should be the preferred way to use fetch_all. Why store the data only to dump it into a PHP array on the next line? That is a very inefficient use of memory and plain careless development. Or do you mean to say that fetch_all is fundamentally broken and will only work with STORE_RESULT? Previous Comments: [2010-07-13 10:36:22] and...@php.net Makes no sense to use USE_RESULT and buffer the result. Use STORE_RESULT, it is more effective for fetch_all(). Artifically limited. [2010-07-12 18:16:35] brad at njoe dot com Confirmed on Windows build as well using: PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13). Even SELECT'ing a static string (e.g. SELECT 'This is a test.') exhibits this behavior. [2010-07-10 10:39:32] brianlm...@php.net Description: When using MYSQLI_USE_RESULT as the second parameter to mysqli_query, fetch_all returns null. Test script: --- query($sql, MYSQLI_USE_RESULT); $rows = $res->fetch_all(); var_dump($rows); ?> Expected result: An array of the table data. Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/bug.php?id=52302&edit=1
Req #52302 [Csd]: mysqli_fetch_all does not work with MYSQLI_USE_RESULT
Edit report at http://bugs.php.net/bug.php?id=52302&edit=1 ID: 52302 Updated by: brianlm...@php.net Reported by:brianlm...@php.net Summary:mysqli_fetch_all does not work with MYSQLI_USE_RESULT Status: Closed Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: Can we get an E_WARNING when fetch_all is called with a result handle that is using USE_RESULT? Can the documentation be updated to include a notice that this will not work? Previous Comments: [2010-08-09 19:37:18] and...@php.net Fix will appear in 5.3.4 In any case, it is sub-optimal to use MYSQLI_USE_RESULT with fetch_all, compared to MYSQLI_STORE_RESULT. However, fetch_all with USE_RESULT should be faster than manually looping. [2010-08-09 19:29:32] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=302045 Log: Fix Request #52302 mysqli_fetch_all does not work with MYSQLI_USE_RESULT [2010-08-05 14:11:27] johan...@php.net The key point here is that the stored buffer can directly be used for fetch_all. The fetch_all does nothing but increasing the ref counts on the buffered values and adding them to an array. doing this with USE_RESULT would do an implicit STORE_RESULT. Marking this a Feature request. [2010-07-16 17:42:59] brianlm...@php.net No, it makes perfect sense. In fact, it should be the preferred way to use fetch_all. Why store the data only to dump it into a PHP array on the next line? That is a very inefficient use of memory and plain careless development. Or do you mean to say that fetch_all is fundamentally broken and will only work with STORE_RESULT? [2010-07-13 10:36:22] and...@php.net Makes no sense to use USE_RESULT and buffer the result. Use STORE_RESULT, it is more effective for fetch_all(). Artifically limited. 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=52302 -- Edit this bug report at http://bugs.php.net/bug.php?id=52302&edit=1
#34424 [Bgs]: Fatal error with current(current($x))
ID: 34424
Updated by: [EMAIL PROTECTED]
Reported By: marco at alphasoft dot ch
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows, IIS, Isapi
PHP Version: 5.0.5
New Comment:
This code now works under 5.1. So, is 5.1 broken or was 5.0 borken and
this was a bad dismisal of a bug?
Previous Comments:
[2005-09-08 11:54:57] [EMAIL PROTECTED]
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
.
[2005-09-08 11:50:05] marco at alphasoft dot ch
Description:
Nested current() does not work.
Reproduce code:
---
$a = array(
'a'=>array('b'=>'c')
);
echo current(current($a));
Expected result:
c
Actual result:
--
Fatal error: Only variables can be passed by reference in
--
Edit this bug report at http://bugs.php.net/?id=34424&edit=1
