Closed Bug 464992 Opened 16 years ago Closed 15 years ago

Binary attachments, graphical reports and new charts are not displayed correctly on Windows

Categories

(Bugzilla :: Attachments & Requests, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
Bugzilla 3.2

People

(Reporter: Eric.Olson, Assigned: LpSolit)

References

Details

(Keywords: regression)

Attachments

(6 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 3.2rc2

Binary attachments are not displaying properly. After uploading an image attachment (tried with bmp, gif, png, jpg, and pdf), attempting to display the attachment usually gives an error "The image http://[my domain]/bugzilla-3.2rc2/attachment.cgi?id=5 cannot be displayed because it contains errors." This only seems to happen on my install of version 3.2rc2. I have been unable to replicate this problem with a brand-new install of 3.0.6.

If I get the XML version of the bug, cut and paste the attachment information out of it, and manually decode the base64 text, the attachment comes out fine. I've also checked the contents of the attach_data table for the 3.2rc2 and 3.0.6 installs, and they appear to be identical. I've also been unable to replicate this at landfill.bugzilla.org.

Reproducible: Always

Steps to Reproduce:
1. Attach a binary attachment, auto-detecting the content type.
2. Attempt to display the attachment, either by clicking on the attachment name or the Details link.
Actual Results:  
A corrupted binary file that doesn't display properly.


I'm running on Windows XP, Apache 2.2, and mySQL 5.0.
I cannot reproduce the problem, neither on Linux nor Windows. I tested with BMP and JPG files, and both display correctly. Also, the fact that you cannot reproduce on landfill may indicate a problem with your installation, either your copy of Bugzilla or your web server.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 3.2
1. And what content-types were auto-detected?
2. Could you reproduce on the same instance with other browser (Firefox?)
(In reply to comment #2)
> 1. And what content-types were auto-detected?

Yeah, content-types are sent by the browser. If IE6 sends wrong content-types, that's a bug in IE6, not in Bugzilla. FYI, I tested with Firefox 3.1.
1. Content types were correctly auto-detected as image/gif, image/png, etc. I've also tried selecting the type from the drop down box when uploading an attachment and even by typing it in manually.
2. I can reproduce this on Firefox 3.0.4 and IE7 under Windows and Konqueror under Linux.
3. If this was a misconfiguration somewhere in the webserver, I'd expect the problem to happen under both 3.0 and 3.2, not just 3.2. I tried setting the default Apache content type as application/octet-stream, but that had no effect. I can't find any relevant Bugzilla configuration parameter to experiment with.
So one can tell it is _stored_ correctly, but somehow _served_ wrong?

Test proposal: use 'wget -v' to save the link .  Then compare original and served file, and also look for any pecularities in http reported by wget.
There were no differences in the http reported by wget. I'm now pretty sure this is some sort of character encoding issue. I created a binary file consisting only of the 255 bytes 0x00 0x01 ... 0xFF and used that as my attachment. When I view or download the attachment, bytes less that 0x80 are fine. Anything above 0x80 comes back as two bytes, with 0xC2 as the first byte. The file is also truncated to the same length as the original file. 

The attachment is intact in the attach_data table, because SELECT ... INTO OUTFILE binaryfile.txt gives me the original binary contents (with some special characters, e.g. 0x00, escaped).  So it looks like the attachment is getting encoded as UTF-8 instead of left as plain binary.

This still happens only with my install of 3.2rc2, not with my install of 3.0.6 or with the landfill.bugzilla.org 3.2 branch.
1. What MySQL charset is used by your database?
2. Kindly attach output of `checksetup.pl --check-modules`
3. Do not laugh, but: can you reproduce bug 457524 on your instance?
1. According to mySQL:
character_set_client     latin1
character_set_connection latin1
character_set_database   utf8
character_set_filesystem binary
character_set_results    latin1
character_set_server     latin1

2. See attached.

3. Yes I can. After installing the Russian localization (though I'm not sure how to start *using* it; everything's still in English), bugs made against a component with a Russian name do not show up in tabular reports.
Results of "perl checksetup.pl --check-modules"
I have exactly the same problem on Windows 2008 Server Standard x64 SP1 Russian with last installed 

updates, Apache 2.2.8 x86, Perl 5.8.8 x86, Bugzilla 3.2 english release (without localization).

MySQL character sets:

character_set_client      utf8
character_set_connection  utf8
character_set_database    utf8
character_set_filesystem  binary
character_set_results     utf8
character_set_server      utf8
character_set_system      utf8
collation_connection      utf8_general_ci
collation_database        utf8_general_ci
collation_server          utf8_general_ci


Results of checksetup.pl --check-modules:

* This is Bugzilla 3.2 on perl 5.8.8
* Running on WinVista Build 6001 (Service Pack 1)

Checking perl modules...
Checking for              CGI.pm (v3.21)   ok: found v3.41
Checking for            TimeDate (v2.21)   ok: found v2.22
Checking for           PathTools (v0.84)   ok: found v3.2701
Checking for                 DBI (v1.41)   ok: found v1.607
Checking for    Template-Toolkit (v2.15)   ok: found v2.20
Checking for          Email-Send (v2.16)   ok: found v2.192
Checking for          Email-MIME (v1.861)  ok: found v1.861
Checking for Email-MIME-Modifier (v1.442)  ok: found v1.442

Checking available perl DBD modules...
Checking for              DBD-Pg (v1.45)    not found
Checking for           DBD-mysql (v4.00)   ok: found v4.005
Checking for          DBD-Oracle (v1.19)   ok: found v1.21

The following Perl modules are optional:
Checking for                  GD (v1.20)   ok: found v2.41
Checking for               Chart (v1.0)    ok: found v2.3
Checking for         Template-GD (any)     ok: found v1.56
Checking for          GDTextUtil (any)     ok: found v0.86
Checking for             GDGraph (any)     ok: found v1.44
Checking for            XML-Twig (any)     ok: found v3.32
Checking for          MIME-tools (v5.406)  ok: found v5.427
Checking for         libwww-perl (any)     ok: found v5.814
Checking for         PatchReader (v0.9.4)  ok: found v0.9.5
Checking for          PerlMagick (any)      not found
Checking for           perl-ldap (any)     ok: found v0.39
Checking for         Authen-SASL (any)     ok: found v2.12
Checking for          RadiusPerl (any)     ok: found v0.13
Checking for           SOAP-Lite (any)     ok: found v0.69
Checking for         HTML-Parser (v3.40)   ok: found v3.59
Checking for       HTML-Scrubber (any)     ok: found v0.08
Checking for Email-MIME-Attachment-Stripper (any)     ok: found v1.315
Checking for         Email-Reply (any)     ok: found v1.202
Checking for            mod_perl (v1.999022)  not found
Checking for              CGI.pm (v3.11)   ok: found v3.41
Another symptom likely introduced by attachment 286357 [details] [diff] [review]

You may try to revert this patch and check the result.
I've manually reverted this patch and now attachments displayed correctly. But now it's unable to use localization (Russian), because all non-ascii characters in form fields displayed incorrectly.
The problem has also solved by another way: on clean installation of Bugzilla 3.2 (release) I've changed file "Bugzilla/Util.pm":

sub disable_utf8 {
    if (Bugzilla->params->{'utf8'}) {
        # binmode STDOUT, ':raw'; # Turn off UTF8 encoding.
        binmode STDOUT, ':bytes'; # Turn off UTF8 encoding (old method, but it's work!).
    }
}
Could someone try :bytes on Unix?  If harmless, it may not be a workaround but a solution...
Flags: blocking3.2.1?
I've seen a few people report this. I can't say whether or not it's a blocker, though, until we understand more about it. Is this a bug in ActiveState, or...?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Could someone attach the broken binary attachiment file?
Save from browsers or via 'wget'-liked program.
Yes, I could.
The first file is original binary file named "x00-xFF_original.bin", containing 256 bytes from x00 to xFF in succession, when I was creating this attachment in Bugzilla, I manually defined the content-type as "application/octet-stream".
The second file named "x00-xFF_downloaded.bin" is file downloaded from Bugzilla (from Opera 9.62).
Attached file Original binary file
This may affect graphical reports, as well. See http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/f86fec59c2fa99f5#
Hmmm, do you think it's possible that the underlying problem is the same as the one of bug 467920?
Yes, bug 469794, bug 467920 share the same root cause: patch from bug 363153.  Noticed by himorin.
OK. I confirm this problem as an utf8 related one.
But cannot confirm as bugzilla's one, now. b/c I've not read codes.
As attached file, each raw byte are transcoded with utf-8's bit pattern. Like,
\u80 to \u7FF (0000 0aaa bbbb cccc) => 110a aabb 10bb cccc
And data 'might be' truncated to the original attachment size.

I think we should confirm whether the data registoration procedure is wrong or the data retrieve procedure is wrong.

Leonid, if you can access to the detabase, could you try the following SQL?
SELECT BIT_LENGTH(thedata) FROM attach_data WHERE id = <attach-id>; (mysql)
(In reply to comment #24)
> Leonid, if you can access to the detabase, could you try the following SQL?
> SELECT BIT_LENGTH(thedata) FROM attach_data WHERE id = <attach-id>; (mysql)

ah, of cource, the aim of this is to check WHERE the data is transcoded.
If file size at attaching != size at database, we should check the attaching code.
If not, i think we should focus on the downloading code.
That's it:

mysql> SELECT BIT_LENGTH(thedata) FROM attach_data WHERE id = 1;
+---------------------+
| BIT_LENGTH(thedata) |
+---------------------+
|                2048 |
+---------------------+
1 row in set (0.00 sec)
Keywords: qawanted
Did some quick trial-and-error changes (as I needed to get attachments working again) and was able to fix it for me by removing the changes in Bugzilla.pm introduced in attachment 286357 [details] [diff] [review] - didn't do a full test (just added an attachment and opened it as well as a couple of old ones). 
Didn't touch the other files. Hope that helps.
Hi,

On a clean install i managed to get my attachements working by following Comment #14 From Leonid Rogov. But Graphs (New chart and Graphical Reports) do not work.
I confirm the last comment from Mubashir, my bugzilla also has the broken chart and report images with or without having changes from comment #14.
It looks like to me as there are two problems which are independent of each other. One to do with the attachements and the second with the Graphiacl reports. So may be we should raise a new bug against component Reporting/Charting. Let me know if any one disagree with it else i will try to raise a bug as more and more people are complaining about it now. 

Regards,
Mubashir
Confirmed for Bugzilla 3.2 on Windows Server 2003 x64, MySQL 5.1.30, Apache 2.0.63

Comment #14 solved this issue for attachments for me. 

Graphs etc. still do not work.
Is there already a "new bug against component Reporting/Charting" ?!
Yes, i have recently raised a bug against Reporting/Charting component for graphical report and new charts problem. https://bugzilla.mozilla.org/show_bug.cgi?id=470486 (Bug number 470486).
As I said in bug 470486 comment 4, I cannot reproduce your problem on http://windows.bugzilla.org/qa32win/ which is running Windows 2003.
See bug 470486 comment 7 for details
(In reply to comment #34)
> As I said in bug 470486 comment 4, I cannot reproduce your problem on
> http://windows.bugzilla.org/qa32win/ which is running Windows 2003.

What version of perl is this server using? Isn't it perl 5.10?

I could reproduce with using perl 5.8.8 on Windows Server 2003.
.bin.orig is the original file uploaded, .bin is the downloaded file from bugzilla 3.2 on Windows Server 2003.
% ls -l x00-xFF_original.bin*
384 Dec 30 16:46 x00-xFF_original.bin
256 Dec 30 16:45 x00-xFF_original.bin.orig
(In reply to comment #36)
> I could reproduce with using perl 5.8.8 on Windows Server 2003.

Sorry. 5.8.9.
Same for perl 5.8.8 (824).
# And i've failed and destroied my test environment :-D
One important update: The work around provided in comment # 14 will enable you to view or download the existing attachments but you wont be able to add new attachments to the bugs. 
i.e. without modifying the original file you can add attachments but can't view it. With modification, you can view them but not add new attachments.

I've also got machine with Bugzilla 3.2 running on Windows XP. Let me know if you need anything which could help you with investigation for this problem.
Unable to reproduce on:

* This is Bugzilla 3.2 on perl 5.10.0
* Running on WinXP/.Net Build 2600 (Service Pack 2)

Checking perl modules...
Checking for              CGI.pm (v3.33)   ok: found v3.41
Checking for            TimeDate (v2.21)   ok: found v2.22
Checking for           PathTools (v0.84)   ok: found v3.2501
Checking for                 DBI (v1.41)   ok: found v1.607
Checking for    Template-Toolkit (v2.15)   ok: found v2.20
Checking for          Email-Send (v2.16)   ok: found v2.192
Checking for          Email-MIME (v1.861)  ok: found v1.861
Checking for Email-MIME-Modifier (v1.442)  ok: found v1.442

Checking available perl DBD modules...
Checking for              DBD-Pg (v1.45)    not found
Checking for           DBD-mysql (v4.00)   ok: found v4.005
Checking for          DBD-Oracle (v1.19)    not found

The following Perl modules are optional:
Checking for                  GD (v1.20)   ok: found v2.41
Checking for               Chart (v1.0)    ok: found v2.4.1
Checking for         Template-GD (any)     ok: found v1.56
Checking for          GDTextUtil (any)     ok: found v0.86
Checking for             GDGraph (any)     ok: found v1.44
Checking for            XML-Twig (any)     ok: found v3.32
Checking for          MIME-tools (v5.406)  ok: found v5.427
Checking for         libwww-perl (any)     ok: found v5.814
Checking for         PatchReader (v0.9.4)  ok: found v0.9.5
Checking for          PerlMagick (any)      not found
Checking for           perl-ldap (any)     ok: found v0.39
Checking for         Authen-SASL (any)     ok: found v2.12
Checking for          RadiusPerl (any)     ok: found v0.13
Checking for           SOAP-Lite (any)     ok: found v0.69
Checking for         HTML-Parser (v3.40)   ok: found v3.59
Checking for       HTML-Scrubber (any)     ok: found v0.08
Checking for Email-MIME-Attachment-Stripper (any)     ok: found v1.315
Checking for         Email-Reply (any)     ok: found v1.202
Checking for            mod_perl (v1.999022) ok: found v2.000004
I had this problem with MS Word file attachments on Bugzilla 3.2/Windows Server 2003/Perl 5.8.8/MySQL 5.0.67. Charting was also broken.

Saving the blob data to disk from the 'thedata' column of the 'attach_data' table in my 'bugs' database confirmed that the files had been uploaded properly, and that the problem lies in the download.

Upgrading Perl to 5.10.0 fixed the attachment and charting problems for me.
> Upgrading Perl to 5.10.0 fixed the attachment and charting problems for me.

Could you compare Perl module versions before and after upgrade?  Or at least post your current module versions?
> Could you compare Perl module versions before and after upgrade?  Or at least
> post your current module versions?

Here's the after, didn't get a before unfortunately.

* This is Bugzilla 3.2 on perl 5.10.0
* Running on Win2003 Build 3790 (Service Pack 2)

Checking perl modules...
Checking for              CGI.pm (v3.33)   ok: found v3.41 
Checking for            TimeDate (v2.21)   ok: found v2.22 
Checking for           PathTools (v0.84)   ok: found v3.2501 
Checking for                 DBI (v1.41)   ok: found v1.607 
Checking for    Template-Toolkit (v2.15)   ok: found v2.20 
Checking for          Email-Send (v2.16)   ok: found v2.194 
Checking for          Email-MIME (v1.861)  ok: found v1.861 
Checking for Email-MIME-Modifier (v1.442)  ok: found v1.442 

Checking available perl DBD modules...
Checking for              DBD-Pg (v1.45)    not found 
Checking for           DBD-mysql (v4.00)   ok: found v4.005 
Checking for          DBD-Oracle (v1.19)   ok: found v1.21 

The following Perl modules are optional:
Checking for                  GD (v1.20)   ok: found v2.41 
Checking for               Chart (v1.0)    ok: found v2.4.1 
Checking for         Template-GD (any)     ok: found v1.56 
Checking for          GDTextUtil (any)     ok: found v0.86 
Checking for             GDGraph (any)     ok: found v1.44 
Checking for            XML-Twig (any)     ok: found v3.32 
Checking for          MIME-tools (v5.406)  ok: found v5.427 
Checking for         libwww-perl (any)     ok: found v5.814 
Checking for         PatchReader (v0.9.4)  ok: found v0.9.5 
Checking for          PerlMagick (any)      not found 
Checking for           perl-ldap (any)     ok: found v0.39 
Checking for         Authen-SASL (any)     ok: found v2.12 
Checking for          RadiusPerl (any)     ok: found v0.13 
Checking for           SOAP-Lite (any)     ok: found v0.69 
Checking for         HTML-Parser (v3.40)   ok: found v3.56 
Checking for       HTML-Scrubber (any)     ok: found v0.08 
Checking for Email-MIME-Attachment-Stripper (any)     ok: found v1.315 
Checking for         Email-Reply (any)     ok: found v1.202 
Checking for            mod_perl (v1.999022) ok: found v2.000004 

* NOTE: You must run any commands listed below as Administrator.

***********************************************************************
* Note For Windows Users                                              *
***********************************************************************
* In order to install the modules listed below, you first have to run * 
* the following command as an Administrator:                          *
*                                                                     *
*   ppm repo add theory58S http://cpan.uwinnipeg.ca/PPMPackages/10xx/
*                                                                     *
***********************************************************************
**********************************************************************
* OPTIONAL MODULES                                                   *
**********************************************************************
* Certain Perl modules are not required by Bugzilla, but by          *
* installing the latest version you gain access to additional        *
* features.                                                          *
*                                                                    *
* The optional modules you do not have installed are listed below,   *
* with the name of the feature they enable. If you want to install   *
* one of these modules, just run the appropriate command in the      *
* "COMMANDS TO INSTALL" section.                                     *
**********************************************************************

***********************************************************************
* MODULE NAME * ENABLES FEATURE(S)                                    *
***********************************************************************
*  PerlMagick * Optionally Convert BMP Attachments to PNGs            *
***********************************************************************
COMMANDS TO INSTALL:

     PerlMagick: ppm install PerlMagick
(In reply to comment #39)
> One important update: The work around provided in comment # 14 will enable you
> to view or download the existing attachments but you wont be able to add new
> attachments to the bugs. 

I can upload and download attachments with this workaround.
There is a new development on this one. I have recently installed Bugzilla 3.2 with the latest MySQL, Perl on Windows Vista 32 bit machine with Apache webserver. The only difference this time is in the past i was using XP with IIS and installed bugzilla using Tar ball where attachments seem to fail. This time i installed it using CVS (fresh install) with Apache, and attachments seem to be working fine without any workaround.
Confirming the bug per the number of users complaining in the support newsgroup. I have a patch which has been successfully tested by a user affected by the problem. Please apply the patch to your installation too, and tell me if it also fixes the problem for you.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Binary attachments not displaying correctly → Binary attachments, graphical reports and new charts are not displayed correctly on Windows
Target Milestone: --- → Bugzilla 3.2
Attached patch patch, v1 (obsolete) — Splinter Review
Test this. And if someone understands why ':bytes' fixes the problem on Windows, please explain to me, because I have absolutely no idea.
Assignee: attach-and-request → LpSolit
Status: NEW → ASSIGNED
Attachment #356063 - Flags: review?
Comment on attachment 356063 [details] [diff] [review]
patch, v1

:bytes is the opposite of :utf8. So it would be appropriate for it to be in disable_utf8. However, you'd still have to do "binmode STDOUT" in places where STDOUT is supposed to be spewing binary data.

See http://perldoc.perl.org/PerlIO.html
Attachment #356063 - Flags: review? → review-
(In reply to comment #49)
> :bytes is the opposite of :utf8. So it would be appropriate for it to be in
> disable_utf8. However, you'd still have to do "binmode STDOUT" in places where
> STDOUT is supposed to be spewing binary data.

Yeah, but this patch is more a workaround than a real fix. I didn't want to introduce other regressions.
Hi Frédéric,

The patch has fixed the problem on my faulty XP machine running with IIS and Bugzilla 3.2. Both attachments and graphs / charts are working fine.

Thanks,
Mubashir
OK, now that we know my patch fixes problems on Windows, it makes sense to wait for it before releasing 3.2.1.
Flags: blocking3.2.1? → blocking3.2.1+
Keywords: qawantedregression
(In reply to comment #50)
> Yeah, but this patch is more a workaround than a real fix. I didn't want to
> introduce other regressions.

  Okay. Let's come up with a solid fix for the tip and then see if we can do a hacky fix for the branch if necessary, then.
(In reply to comment #48)
> Created an attachment (id=356063) [details]
> patch, v1
> 
> Test this. And if someone understands why ':bytes' fixes the problem on
> Windows, please explain to me, because I have absolutely no idea.

Ok. I confirm this patch working well (for the attachment issue) on my windows test server. (perl 5.8.9 on Windows 2003 Server, modules are the same as the previous attachment.)
And, doesn't harm on debian 4.0 test server. (below)

* This is Bugzilla 3.2 on perl 5.8.8
* Running on Linux 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007
Confirm, this work for attachments, graph-reports and charts.

Bugzilla 3.2
Perl 5.8.8
Windows 2008 Server Std Russian
Attached file test script for PerlIO
I think this is something a bug on ActivePerl.
With attached script, output should be
>c:\Perl\bin\perl.exe perlio.pl
5.10.0
crlf
utf8
crlf
crlf

But, with using 5.8.9 whose downloaded attachment is broken,
>c:\perl\bin\perl.exe perlio.pl
5.8.9
crlf
utf8
utf8
crlf
(In reply to comment #56)
> I think this is something a bug on ActivePerl.

  Hmm. Are you saying this works in 5.10?

  In any case, now that you have that test script, we should probably report the bug to ActiveState. They have a Bugzilla here:

  http://bugs.activestate.com/
Attached patch patch, v2Splinter Review
OK, here is a nicer patch. I checked, and only attachments use disable_utf8(), so there are much less places using it than expected, which limits the risk to regress something. :)

To all of you who tested my previous patch, could you test this new one please, and tell me if it still works correctly for you? Many thanks!

And thanks again to Rob Jackson who already tested my patch on his installation (successfully).
Attachment #356063 - Attachment is obsolete: true
Attachment #356992 - Flags: review?(mkanat)
Attachment #356992 - Flags: review?(mkanat) → review+
Comment on attachment 356992 [details] [diff] [review]
patch, v2

>Index: report.cgi
>+disable_utf8() if ($format->{'ctype'} eq 'image/png');

  We should probably just check if it starts with "image/" in case somebody has modified the types of report images their installation sends.


  Otherwise, in testing this works fine, so let's just fix the above thing on checkin.
(In reply to comment #59)
>   We should probably just check if it starts with "image/" in case somebody has
> modified the types of report images their installation sends.

OK, I will do that.
Flags: approval3.2+
Flags: approval+
tip:

Checking in chart.cgi;
/cvsroot/mozilla/webtools/bugzilla/chart.cgi,v  <--  chart.cgi
new revision: 1.28; previous revision: 1.27
done
Checking in report.cgi;
/cvsroot/mozilla/webtools/bugzilla/report.cgi,v  <--  report.cgi
new revision: 1.44; previous revision: 1.43
done
Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.80; previous revision: 1.79
done


3.2:

Checking in chart.cgi;
/cvsroot/mozilla/webtools/bugzilla/chart.cgi,v  <--  chart.cgi
new revision: 1.26.2.1; previous revision: 1.26
done
Checking in report.cgi;
/cvsroot/mozilla/webtools/bugzilla/report.cgi,v  <--  report.cgi
new revision: 1.41.2.1; previous revision: 1.41
done
Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.69.2.7; previous revision: 1.69.2.6
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago15 years ago
Resolution: --- → FIXED
OK, the patch v2 is worked, thanks.
Also thanks that you have used my idea (from comment #14) for a basis of this patch =)
(In reply to comment #57)
> > I think this is something a bug on ActivePerl.
> 
>   Hmm. Are you saying this works in 5.10?

Yes. Works in ActivePerl/5.10 and perl on cygwin or linux box etc.
This is consistent with the reports to us about this bug.

# If it possible, and i think it's possible with some util function (used in checksetup.pl to get ActivePerl revision), might it be better to filter whether to use :raw or :bytes in disable_utf8()?

>   In any case, now that you have that test script, we should probably report
> the bug to ActiveState. They have a Bugzilla here:
> 
>   http://bugs.activestate.com/

filed. http://bugs.activestate.com/show_bug.cgi?id=81631
You need to log in before you can comment on or make changes to this bug.