Bug 100577 - String::fromUTF8() should take advantage of the ASCII check in convertUTF8ToUTF16()
Summary: String::fromUTF8() should take advantage of the ASCII check in convertUTF8ToU...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Michael Saboff
URL:
Keywords:
Depends on: 102482
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-26 16:47 PDT by Michael Saboff
Modified: 2012-11-16 12:18 PST (History)
5 users (show)

See Also:


Attachments
Patch (1.63 KB, patch)
2012-10-26 17:30 PDT, Michael Saboff
no flags Details | Formatted Diff | Diff
Patch with ASSERTS to find GTK and Qt failures (1.76 KB, patch)
2012-11-12 09:25 PST, Michael Saboff
no flags Details | Formatted Diff | Diff
Updated patch with debugging (2.76 KB, patch)
2012-11-14 13:57 PST, Michael Saboff
no flags Details | Formatted Diff | Diff
http/tests/plugins/get-url-stderr.txt (1.07 MB, text/plain)
2012-11-15 05:28 PST, Csaba Osztrogonác
no flags Details
Another Debug Patch (2.84 KB, patch)
2012-11-15 08:22 PST, Michael Saboff
no flags Details | Formatted Diff | Diff
http/tests/plugins/get-url-stderr.txt (1.08 MB, text/plain)
2012-11-15 09:32 PST, Csaba Osztrogonác
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Saboff 2012-10-26 16:47:03 PDT
By taking advantage of the ASCII check recently added to convertUTF8ToUTF16(), fromUTF8() could create an 8 bit string where possible.
Comment 1 Michael Saboff 2012-10-26 17:30:35 PDT
Created attachment 171060 [details]
Patch
Comment 2 WebKit Review Bot 2012-10-27 11:26:11 PDT
Comment on attachment 171060 [details]
Patch

Clearing flags on attachment: 171060

Committed r132736: <http://trac.webkit.org/changeset/132736>
Comment 3 WebKit Review Bot 2012-10-27 11:26:14 PDT
All reviewed patches have been landed.  Closing bug.
Comment 4 Csaba Osztrogonác 2012-10-29 03:36:57 PDT
(In reply to comment #2)
> (From update of attachment 171060 [details])
> Clearing flags on attachment: 171060
> 
> Committed r132736: <http://trac.webkit.org/changeset/132736>

It broke all plugin tests on WK2 platforms.
- GTK: http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20WK2%20%28Tests%29/r132737%20%282830%29/results.html
- Qt: http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Release%20WebKit2%20%28Amazon%20EC2%29/r132762%20%2810200%29/results.html

Could you check and fix it, please?
Comment 5 WebKit Review Bot 2012-10-29 04:18:56 PDT
Re-opened since this is blocked by bug 100652
Comment 6 Csaba Osztrogonác 2012-10-29 04:25:15 PDT
(In reply to comment #5)
> Re-opened since this is blocked by bug 100652

Rollout landed in http://trac.webkit.org/changeset/132784
Comment 7 Michael Saboff 2012-11-12 09:25:13 PST
Created attachment 173660 [details]
Patch with ASSERTS to find GTK and Qt failures

(In reply to comment #4)
> (In reply to comment #2)
> > (From update of attachment 171060 [details] [details])
> > Clearing flags on attachment: 171060
> > 
> > Committed r132736: <http://trac.webkit.org/changeset/132736>
> 
> It broke all plugin tests on WK2 platforms.
> - GTK: http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20WK2%20%28Tests%29/r132737%20%282830%29/results.html
> - Qt: http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Release%20WebKit2%20%28Amazon%20EC2%29/r132762%20%2810200%29/results.html
> 
> Could you check and fix it, please?

Could you try the attached patch built debug with the WK2 plugin tests and report any failures?
Comment 8 Csaba Osztrogonác 2012-11-13 06:18:03 PST
Sure. I'm on it.
Comment 9 Csaba Osztrogonác 2012-11-13 07:04:06 PST
I ran plugin tests in debug mode with your patch on Qt-WK2, but I 
still get same results as I mentioned previously and no assertion.
Comment 10 Michael Saboff 2012-11-13 08:43:47 PST
(In reply to comment #9)
> I ran plugin tests in debug mode with your patch on Qt-WK2, but I 
> still get same results as I mentioned previously and no assertion.

I'm currently at a loss as to why the plugin tests are failing on just Qt and GTK.

Let me post a patch that will output data from within fromUTF8().  If you run a couple of tests and provide the output, that would be helpful.
Comment 11 Michael Saboff 2012-11-14 13:57:12 PST
Created attachment 174252 [details]
Updated patch with debugging

I think I may have found the issue, but here is a patch with debugging.  I think fromUTF8() isn't handling the case of a valid stringStart but a 0 length.  I added a check for that in this patch.

Please apply this patch and build it debug.  Try LayoutTests/http/tests/plugins/get-url.html and attach the created get-url-stderr.txt.

Then if you could, edit Source/WTF/wtf/text/WTFString.cpp and comment out the line "#define DEBUG_FROMUTF8 1" (~line 862 in my version).  Rebuild and retest.

Thanks in advance.
Comment 12 Csaba Osztrogonác 2012-11-15 05:28:10 PST
Created attachment 174412 [details]
http/tests/plugins/get-url-stderr.txt
Comment 13 Csaba Osztrogonác 2012-11-15 05:35:43 PST
After commenting out "#define DEBUG_FROMUTF8 1" line, plugin tests still fail. :(
Comment 14 Michael Saboff 2012-11-15 08:22:57 PST
Created attachment 174447 [details]
Another Debug Patch

Thanks for the last output.  I still think there is an issue with length == 0.  I modified what happens in that case and changed the debugging a little.  Please try this one as well, including with the "#define DEBUG_FROMUTF8 1" removed.

Thanks.
Comment 15 Csaba Osztrogonác 2012-11-15 08:58:10 PST
Let me see.
Comment 16 Csaba Osztrogonác 2012-11-15 09:32:16 PST
Created attachment 174467 [details]
http/tests/plugins/get-url-stderr.txt
Comment 17 Csaba Osztrogonác 2012-11-15 09:42:08 PST
(In reply to comment #16)
> Created an attachment (id=174467) [details]
> http/tests/plugins/get-url-stderr.txt

and plugin tests still fail unfortunately :(
Comment 18 Michael Saboff 2012-11-15 13:30:05 PST
(In reply to comment #16)
> Created an attachment (id=174467) [details]
> http/tests/plugins/get-url-stderr.txt

I've spent some time trying to figure things out from the last debug information.  I still don't understand what the issue is.  At this point, I suspect the plugin process is not getting started, possible due to the path.  Could you spend some time trying to figure out what the issue is?

Let me know if you need anything.

Thanks in advance.
Comment 19 Balazs Kelemen 2012-11-16 04:57:43 PST
I think I found the issue: bug 102482
Comment 20 Balazs Kelemen 2012-11-16 04:59:04 PST
Plugin tests works fine with Qt with this patch and my proposed fix.
Comment 21 Balazs Kelemen 2012-11-16 05:02:35 PST
Btw probably we should have an easy way to force making a 16 bit string null terminated string from a 8 bit source. Probably that would work:

static String make16BitFrom8BitSource(const char* s)
{
    return make16BitFrom8BitSource(reinterpret_cast<const LChar*>(s), strlen(s) + 1);
}
Comment 22 Michael Saboff 2012-11-16 10:13:13 PST
(In reply to comment #21)
> Btw probably we should have an easy way to force making a 16 bit string null terminated string from a 8 bit source. Probably that would work:
> 
> static String make16BitFrom8BitSource(const char* s)
> {
>     return make16BitFrom8BitSource(reinterpret_cast<const LChar*>(s), strlen(s) + 1);
> }

If you need it, add the function.  Note that I think you also need to set s_hashFlagHasTerminatingNullCharacter in the StringImpl m_hashAndFlags.
Comment 23 Michael Saboff 2012-11-16 12:18:42 PST
Committed r134981: <http://trac.webkit.org/changeset/134981>