BIG5....
I guess it's supported by libiconv and  your glibc is ok..

If text is small enough, could you pate uuencoded text there?

Better yet. 

Could you make a script that included base64/uuencoded BIG5 data end decode it and feed it to iconv?

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

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.

Fixed in CVS and 4.2.0 branch.

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.

Yep, saw it. Will fix this later (this day).

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.

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();
?>

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?

fyi..I can't reproduce this on Linux with latest CVS
and with libiconv 1.3.

Assigning to Markus...

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.

Why was this still assigned to me ? :)

Is this bug still occuring in CVS HEAD?

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".