PHP 4.0 Bug #9365 Updated: Problem with muiti-byte char code set (serious)

ID: 9365 User Update by: yohgaki@dd.iij4u.or.jp Status: Open Bug Type: Scripting Engine problem Description: Problem with muiti-byte char code set (serious) At first I should correct that included file that causes this problem is only one file and returning reference from the functions does not make difference. (Script was not uploaded to server. I tested again, the file causes this problem only happens when the file is included, and reference does not make changes) I've tested with 4.0.4pl1 and 4.0.5-dev (200103092045) with - RedHat Linux7/j (glibc is updated to 2.2, gcc also updated - Redhat's RPM) - Apache 1.3.17 w/ mod-ssl, mod-gzip and other apache modules comes with apache. (Tested both w/ and w/o ssl) For 4.0.5-dev, I only add PostgreSQL module. './configure' '--with-apxs' '--disable-short-tags' '--with-pgsql' Results are the same. I also included the file that causes this from other script. The file is included w/o any problems. I tried to make a simple script that reproduce this problem again, but I could not. Since I can easily workaround with this problem and I've seen this only once so far, I'll leave this problem. (If I don't use function, the code works as expected) If you have similar bug report and need more info, please let me know. PS: Someone post similar problem regarding ob_ob_get_contents(). I asked what kind of environment he uses. I'll post report, if I can find out anything. Previous Comments: --------------------------------------------------------------------------- [2001-03-09 23:34:55] yohgaki@dd.iij4u.or.jp I forgot comment that it does not happen with simple scripts that have the same logic. So trying to make a script that causes this problem is just a waste of your time. I'll test some more, so please wait feedback. --------------------------------------------------------------------------- [2001-03-09 23:14:11] yohgaki@dd.iij4u.or.jp It seems it is related to reference. The registration is done in a function and if there are error the function returns array contains error messages. It can be relatively large, so I returned reference. I get rid of the reference, then it start working as it should. i.e. function &register() <= script executed from the beginning. function register() <= works as it should. Hope this info helps. --------------------------------------------------------------------------- [2001-03-09 23:03:45] yohgaki@dd.iij4u.or.jp I tested with Newer Japanese Charset Handling module. => the same result. Without these modules => the same result. I was compiled in these Japanese char handling modules in php. I didn't compile these modules in php, but I compile these modules as individual *.so file. The same result. If I use plain ASCII HTML file for include(). It works. But not with HTML contains EUC. I'll upgrade my glibc see if it fixes. (Please wait for feedback) FYI: Code that causes this. I've tested with require()/include_once()/require_once(), the same result. Reminder - Include()/require() works fine except on this file. ------------------ // Show Registration complete html //die('DIED BEFORE INCLUDE'); // Dies as it should //header('Location: http://www/'); // Just for testing //include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again from the beginning!! Can't even die at the beginning of the file. //include('test3.php'); // ASCII char only. Works as expected. include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from the beginning!! Can't even die at the beginning of the file. die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should. -------------------- --------------------------------------------------------------------------- [2001-03-09 22:52:46] yohgaki@dd.iij4u.or.jp I tested with Newer Japanese Charset Handling module. => the same result. Without these modules => the same result. I was compiled in these Japanese char handling modules in php. I didn't compile these modules in php, but I compile these modules as individual *.so file. The same result. If I use plain ASCII HTML file for include(). It works. But not with HTML contains EUC. I'll upgrade my glibc see if it fixes. (Please wait for feedback) FYI: Code that causes this. I've tested with require()/include_once()/require_once(), the same result. Reminder - Include()/require() works fine except on this file. ------------------ // Show Registration complete html //die('DIED BEFORE INCLUDE'); // Dies as it should //header('Location: http://www/'); // Just for testing //include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again from the beginning!! Can't even die at the beginning of the file. //include('test3.php'); // ASCII char only. Works as expected. include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from the beginning!! Can't even die at the beginning of the file. die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should. -------------------- --------------------------------------------------------------------------- [2001-03-08 07:11:18] yohgaki@dd.iij4u.or.jp I thought I put some code, but there is not.... Anyway, I found the line causes "goto" like behaviour. It was the line to include HTML file to show users. (Note: I still have code that alway do that, I tried to make it simple. So far no luck, if I make it simple, it starts working as expected.... I will try again after I upgrade my glibc to see if it fixes the problem) I've tried to stop script execution as follows. die('Die before include'); // Works as expected include('some.html'); die('Die after include); // This will never happen Inside some.html <?php die('Die inside include'); // This will never happen ?> at the beginning of the file. My code has many include/require like this. This only happens on the script, but not others. Other scripts work fine. All I can tell is something happens when the file is included. Although, the file can be included w/o problems from other scripts. I'll post follow up. Because I didn't test the script after I upgraded Japanese Charactor handling module. It might be gone. (I hope) --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=9365