php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15799 Another segfault on iconv
Submitted: 2002-02-28 19:21 UTC Modified: 2002-09-09 01:00 UTC
From: jan at horde dot org Assigned:
Status: No Feedback Package: ICONV related
PHP Version: 4.0CVS-2002-02-2 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jan at horde dot org
New email:
PHP Version: OS:

 

 [2002-02-28 19:21 UTC] jan at horde dot org
Hi, it's me again.
I got another segfault, this time with the iconv output buffer handler, though iconv() seems to work now, somehow.

That's the code:

        iconv_set_encoding('input_encoding', 'BIG5');
        iconv_set_encoding('internal_encoding', 'UTF-8');
        iconv_set_encoding('output_encoding', 'UTF-8');
        ob_start('ob_iconv_handler');
        echo $text;
        $return = ob_get_contents();
        ob_end_clean();

$text contains a BIG5 encoded message of course.

This is the bt:

Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at malloc.c:3049
3049    malloc.c: No such file or directory.
(gdb) 
(gdb) bt
#0  0x4010621a in chunk_free (ar_ptr=0x89fff7cb, p=0x404e8108) at malloc.c:3049
#1  0x401061bf in free () at malloc.c:2952
#2  0x40372aac in zif_iconv_set_encoding () at iconv.c:174
#3  0x40316987 in execute () at ./zend_execute.c:959
#4  0x40316baf in execute () at ./zend_execute.c:959
#5  0x403288c4 in zend_execute_scripts () at zend.c:373
#6  0x4033c507 in php_execute_script () at main.c:1265
#7  0x40336b40 in apache_php_module_main () at sapi_apache.c:100
#8  0x40337ad8 in send_php (r=0x81823a0, display_source_mode=0, 
    filename=0x81841b0 "/usr/local/httpd/htdocs/headhorde/imp/view.php")
    at mod_php4.c:575
#9  0x40337b63 in send_parsed_php (r=0x81823a0) at mod_php4.c:590
#10 0x8055250 in ap_invoke_handler ()
#11 0x80677bc in ap_some_auth_required ()
#12 0x8067833 in ap_process_request ()
#13 0x805fd27 in ap_child_terminate ()
#14 0x805fed5 in ap_child_terminate ()
#15 0x8060016 in ap_child_terminate ()
#16 0x8060628 in ap_child_terminate ()
#17 0x8060e95 in main ()
#18 0x400cca8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-28 19:32 UTC] yohgaki@php.net
BIG5....
I guess it's supported by libiconv and  your glibc is ok..

If text is small enough, could you pate uuencoded text there?
 [2002-02-28 20:26 UTC] yohgaki@php.net
Better yet. 

Could you make a script that included base64/uuencoded BIG5 data end decode it and feed it to iconv?
 [2002-03-09 11:19 UTC] jan at horde dot org
The segfaults still happen even after the recent changes in the iconv extension and the output buffering code.

Here is a small script to reproduce it. Method 1 (commented out) works fine, method 2 segfaults.

<?
error_reporting(E_ALL);

$text = <<< END
Thanks !!
David Chang
    

-----------------------------------------------------------------
< ?C?ѳ? Yahoo!?_?? >  www.yahoo.com.tw
END;
  

// Method 1: Works!
/*
$src = 'BIG5';
$dst = 'UTF-8';

$rc = iconv($src, $dst, $text);
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
*/


// Method 2: Segfaults!
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$rc = ob_get_contents();
ob_end_clean();

header('Content-Type: text/plain; charset=UTF-8');
echo $rc;

?>

Since the line numbers changed since my initial report and I use a different script (above), here's also an updated bt:

Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at malloc.c:3049
3049    malloc.c: No such file or directory.
(gdb) bt
#0  0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at malloc.c:3049
#1  0x401061bf in free () at malloc.c:2952
#2  0x403744ec in zif_iconv_set_encoding () at iconv.c:267
#3  0x40317077 in execute () at ./zend_execute.c:959
#4  0x40328fb4 in zend_execute_scripts () at zend.c:373
#5  0x4033cea7 in php_execute_script () at main.c:1309
#6  0x40337240 in apache_php_module_main () at sapi_apache.c:100
#7  0x403381d8 in send_php (r=0x81825a0, display_source_mode=0, 
    filename=0x81841a8 "/usr/local/httpd/htdocs/headhorde/iconv.php")
    at mod_php4.c:575
#8  0x40338263 in send_parsed_php (r=0x81825a0) at mod_php4.c:590
#9  0x8055250 in ap_invoke_handler ()
#10 0x80677bc in ap_some_auth_required ()
#11 0x8067833 in ap_process_request ()
#12 0x805fd27 in ap_child_terminate ()
#13 0x805fed5 in ap_child_terminate ()
#14 0x8060016 in ap_child_terminate ()
#15 0x8060628 in ap_child_terminate ()
#16 0x8060e95 in main ()
#17 0x400cca8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93
 [2002-03-09 15:34 UTC] mfischer@php.net
I've sent a patch to jan (wouldn't make sense to paste here as long lines get broken) and I'm pretty sure it's the right fix. I bet the current code never really worked the way it was written.

Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is changing INI settigns which can be easily read and set with ini_get("iconv.input_encoding") or ini_set(). However I don't know what the general consesus in in such situations. The two functions just seem redundant to me.
 [2002-03-10 18:01 UTC] mfischer@php.net
Fixed in CVS and 4.2.0 branch.
 [2002-03-11 05:18 UTC] jan at horde dot org
I see you already committed the patch to cvs and, yes, php doesn't segfault anymore, thanks.

But unfortunately the conversion doesn't happen at all. You can try the same script I posted earlier to reproduce it. Method 1 converts correctly, method 2 just send the Big5 data asis.
 [2002-03-11 05:58 UTC] mfischer@php.net
Yep, saw it. Will fix this later (this day).
 [2002-03-11 17:10 UTC] mfischer@php.net
I'm closing this because I think your code is bogus. The manual clearly says "The function ("ob_iconv_handler") will be called when ob_end_flush() is called, or when the output buffer is flushed to the browser at the end of the request."

So, if you call ob_get_contents() and ob_end_clean() you do not get any conversion. If you either call ob_end_flush() or just don't call any further ob*() functions the conversion works as expected for me.

Feel free to re-open if you think I'm wrong.
 [2002-03-11 17:40 UTC] jan at horde dot org
Ah, you're right, I thought all ob_* functions that return or output the buffer pass the data through the ob_handler first.

But even if I use it the intended way, the output is not converted. This is the new script I used:

<?
error_reporting(E_ALL);

$text = <<< END
Thanks !!
David Chang
    

-----------------------------------------------------------------
< ?C?&#1139;? Yahoo!?_?? >  www.yahoo.com.tw
END;
  
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;

header('Content-Type: text/plain; charset=UTF-8');
ob_end_flush();
?>
 [2002-03-12 01:19 UTC] mfischer@php.net
Yes true ... weird. Upon taking a closer look it seems the iconv fails with 'Invalid or incomplete multibyte or wide character' but the error code is not properly handled in the code in the first and therefore not recognized. Will take a closer look later (this day ;).

Maybe you can verify if your input data really without errors?
 [2002-04-10 19:39 UTC] sniper@php.net
fyi..I can't reproduce this on Linux with latest CVS
and with libiconv 1.3.
 [2002-05-26 14:49 UTC] derick@php.net
Assigning to Markus...
 [2002-05-26 15:00 UTC] mfischer@php.net
Nope, not me. I've no clue what's going on here honestly. I had some talks with Yasou but we didn't came to an end. Reopening.
 [2002-06-02 10:05 UTC] mfischer@php.net
Why was this still assigned to me ? :)
 [2002-08-08 10:26 UTC] kalowsky@php.net
Is this bug still occuring in CVS HEAD?
 [2002-09-09 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Oct 27 12:01:22 2020 UTC