Bug 19580 - REGRESSION (r34432): PGO-only crash in HTMLCollection::resetCollectionInfo (codegen issue?)
Summary: REGRESSION (r34432): PGO-only crash in HTMLCollection::resetCollectionInfo (c...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P1 Major
Assignee: Adam Roben (:aroben)
URL: data:text/html,<form name=myForm><tex...
Keywords: HasReduction, InRadar, PlatformOnly, Regression
: 19752 19763 19818 19934 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-16 08:24 PDT by 808caaa4.8ce9.9cd6c799e9f6
Modified: 2008-07-10 15:59 PDT (History)
13 users (show)

See Also:


Attachments
patch + changelog (2.61 KB, patch)
2008-07-10 15:55 PDT, Adam Roben (:aroben)
zwarich: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description 808caaa4.8ce9.9cd6c799e9f6 2008-06-16 08:24:25 PDT
source:

---
<form name=myForm>
	<textarea name=myText></textarea>
</form>

<script>window.myForm.myText.value='test';</script>
---

debugger outout:
---
Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=0012f250 ecx=7fd1e3a0 edx=00000020 esi=7fd1e3a0 edi=0012f248
eip=100ad160 esp=0012f1dc ebp=0012f1fc iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
WebKit!WebCore__HTMLCollection__resetCollectionInfo+10:
100ad160 8b9800010000     mov     ebx,[eax+0x100]   ds:0023:00000100=????????
0:000> k
ChildEBP RetAddr
0012f1fc 100b592e WebKit!WebCore__HTMLCollection__resetCollectionInfo+0x10
0012f210 100ba061 WebKit!WebCore__HTMLCollection__namedItems+0x1e
0012f230 102cb8c0 WebKit!WebCore__HTMLFormElement__getNamedElements+0x21
0012f258 102669a8 WebKit!WebCore__JSHTMLFormElement__canGetItemsForName+0x40
0012f274 103dc15b WebKit!WebCore__JSHTMLFormElement__getOwnPropertySlot+0x18
0012f2ac 10071956 WebKit!KJS__JSValue__get+0x51
0012f49c 1009dc5f WebKit!KJS__Machine__privateExecute+0x2e86
0012f4f4 1009dad7 WebKit!KJS__Machine__execute+0xcf
0012f53c 1013dfc1 WebKit!KJS__Interpreter__evaluate+0xd7
0012f578 1012ac99 WebKit!WebCore__ScriptController__evaluate+0xb1
0012f594 10023a6e WebKit!WebCore__FrameLoader__executeScript+0x49
0012f758 100326d7 WebKit!WebCore__HTMLTokenizer__scriptExecution+0x10e
0012f7f8 1005e9d9 WebKit!WebCore__HTMLTokenizer__scriptHandler+0x257
0012f830 1005e108 WebKit!WebCore__HTMLTokenizer__parseSpecial+0x369
0012f96c 1005ee32 WebKit!WebCore__HTMLTokenizer__parseTag+0x11a8
7fef7410 00000000 WebKit!WebCore__HTMLTokenizer__write+0x2b2
---

host is safari 4DP(4.526.12.2).
Comment 1 mitz 2008-06-16 10:18:59 PDT
I cannot reproduce the crash on Mac OS X.
Comment 2 Alexey Proskuryakov 2008-06-25 02:18:40 PDT
*** Bug 19763 has been marked as a duplicate of this bug. ***
Comment 3 Alexey Proskuryakov 2008-06-25 02:21:07 PDT
Per bug bug 19763, a crash with this stack trace happens when opening yahoo.com now.
Comment 4 Alexey Proskuryakov 2008-06-25 02:22:16 PDT
<rdar://problem/6033046>
Comment 5 Matt Lilek 2008-06-26 15:35:13 PDT
This doesn't seem to crash with a debug build.
Comment 6 Matt Lilek 2008-06-29 14:05:03 PDT
*** Bug 19818 has been marked as a duplicate of this bug. ***
Comment 7 Adam Roben (:aroben) 2008-06-30 11:46:57 PDT
Looks like m_base->document() is returning 0.
Comment 8 Adam Roben (:aroben) 2008-06-30 11:50:32 PDT
(In reply to comment #7)
> Looks like m_base->document() is returning 0.

This seems to only affect nightly builds, not ToT Safari.
Comment 9 Adam Roben (:aroben) 2008-06-30 20:33:23 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > Looks like m_base->document() is returning 0.
> 
> This seems to only affect nightly builds, not ToT Safari.

Apparently it only affects Release builds, not Debug builds, so my statement above was not quite right (ToT Safari is affected, in Release builds).
Comment 10 Adam Roben (:aroben) 2008-07-01 15:13:20 PDT
data:text/html,<form name=myForm><textarea name=myText></textarea></form><script>window.myForm.myText.value='test';</script>
Comment 11 Adam Roben (:aroben) 2008-07-01 15:21:22 PDT
r34388 does not crash.
Comment 12 Jon Honeycutt 2008-07-01 18:17:23 PDT
<rdar://problem/6029794>
Comment 13 Adam Roben (:aroben) 2008-07-01 18:23:48 PDT
Looks like I narrowed this down incorrectly. It *does* crash in r34503.
Comment 14 Adam Roben (:aroben) 2008-07-01 18:53:25 PDT
It looks like at some point a JSHTMLFormElement is getting passed instead of an HTMLFormElement.
Comment 15 Adam Roben (:aroben) 2008-07-01 18:56:15 PDT
(In reply to comment #14)
> It looks like at some point a JSHTMLFormElement is getting passed instead of an
> HTMLFormElement.

Specifically, HTMLFormElement::elements calls HTMLFormCollection::create and passes in "this", but for some reason "this" is being turned into the JSHTMLFormElement that wraps this HTMLFormElement.
Comment 16 Adam Roben (:aroben) 2008-07-01 18:58:05 PDT
Here's the disassembly for HTMLFormElement::elements:

PassRefPtr<HTMLCollection> HTMLFormElement::elements()
{
00E10710  push        ebp  
00E10711  mov         ebp,esp 
00E10713  push        ecx  
    return HTMLFormCollection::create(this);
00E10714  test        ecx,ecx 
00E10716  push        ecx  
00E10717  mov         dword ptr [esp],ecx 
00E1071A  je          WebCore::HTMLFormElement::elements+0Fh (0E1071Fh) 
00E1071C  inc         dword ptr [ecx+4] 
00E1071F  lea         eax,[ebp-4] 
00E10722  push        esi  
00E10723  push        eax  
00E10724  call        WebCore::HTMLFormCollection::create (0E09F70h) 
00E10729  mov         esi,dword ptr [ebp+8] 
00E1072C  pop         ecx  
00E1072D  pop         ecx  
00E1072E  mov         ecx,dword ptr [eax] 
00E10730  and         dword ptr [eax],0 
00E10733  mov         eax,dword ptr [ebp-4] 
00E10736  test        eax,eax 
00E10738  mov         dword ptr [esi],ecx 
00E1073A  jne         010A4FF6 
00E10740  mov         eax,esi 
00E10742  pop         esi  
}
00E10743  leave            
00E10744  ret         4    
Comment 17 Adam Roben (:aroben) 2008-07-01 19:02:35 PDT
For comparison, here's the disassembly from a Debug build:

PassRefPtr<HTMLCollection> HTMLFormElement::elements()
{
00E318C0  push        ebp  
00E318C1  mov         ebp,esp 
00E318C3  sub         esp,0Ch 
00E318C6  mov         dword ptr [ebp-0Ch],0CCCCCCCCh 
00E318CD  mov         dword ptr [ebp-8],0CCCCCCCCh 
00E318D4  mov         dword ptr [ebp-4],0CCCCCCCCh 
00E318DB  mov         dword ptr [ebp-4],ecx 
    return HTMLFormCollection::create(this);
00E318DE  push        ecx  
00E318DF  mov         ecx,esp 
00E318E1  mov         eax,dword ptr [this] 
00E318E4  push        eax  
00E318E5  call        WTF::PassRefPtr<WebCore::HTMLFormElement>::PassRefPtr<WebCore::HTMLFormElement> (0AE5A06h) 
00E318EA  lea         ecx,[ebp-0Ch] 
00E318ED  push        ecx  
00E318EE  call        WebCore::HTMLFormCollection::create (114B9C0h) 
00E318F3  add         esp,8 
00E318F6  push        eax  
00E318F7  mov         ecx,dword ptr [ebp+8] 
00E318FA  call        WTF::PassRefPtr<WebCore::HTMLCollection>::PassRefPtr<WebCore::HTMLCollection><WebCore::HTMLFormCollection> (0E33E50h) 
00E318FF  lea         ecx,[ebp-0Ch] 
00E31902  call        WTF::PassRefPtr<WebCore::HTMLFormCollection>::~PassRefPtr<WebCore::HTMLFormCollection> (0E32CB0h) 
00E31907  mov         eax,dword ptr [ebp+8] 
}
00E3190A  add         esp,0Ch 
00E3190D  cmp         ebp,esp 
00E3190F  call        WTF::HashTableConstIteratorAdapter<WTF::HashTable<void *,std::pair<void *,PrintJobManager *>,WTF::PairFirstExtractor<std::pair<void *,PrintJobManager *> >,WTF::PtrHash<void *>,WTF::PairHashTraits<WTF::HashTraits<void *>,WTF::HashTraits<PrintJobManager *> >,WTF::HashTraits<void *> >,std::pair<void *,PrintJobManager *> >::operator->+0Ch (6F3FFCh) 
00E31914  mov         esp,ebp 
00E31916  pop         ebp  
00E31917  ret         4    
Comment 18 Adam Roben (:aroben) 2008-07-01 19:27:03 PDT
It looks like in a released version of WebKit.dll HTMLFormElement::elements was inlined within HTMLFormElement::getNamedElements.
Comment 19 Adam Roben (:aroben) 2008-07-01 19:33:42 PDT
(In reply to comment #18)
> It looks like in a released version of WebKit.dll HTMLFormElement::elements was
> inlined within HTMLFormElement::getNamedElements.

Of course that was back before r34432, when HTMLFormCollection::create was added.
Comment 20 Adam Roben (:aroben) 2008-07-01 19:40:07 PDT
(In reply to comment #16)
> Here's the disassembly for HTMLFormElement::elements:
> 
> PassRefPtr<HTMLCollection> HTMLFormElement::elements()
> {
> 00E10710  push        ebp  
> 00E10711  mov         ebp,esp 
> 00E10713  push        ecx  
>     return HTMLFormCollection::create(this);
> 00E10714  test        ecx,ecx 
> 00E10716  push        ecx  
> 00E10717  mov         dword ptr [esp],ecx 
> 00E1071A  je          WebCore::HTMLFormElement::elements+0Fh (0E1071Fh) 
> 00E1071C  inc         dword ptr [ecx+4] 
> 00E1071F  lea         eax,[ebp-4] 
> 00E10722  push        esi  
> 00E10723  push        eax  
> 00E10724  call        WebCore::HTMLFormCollection::create (0E09F70h) 

It looks like the value in esi ends up being the value of the argument passed to HTMLFormCollection::create. If this were working correctly, ecx would be the value passed to HTMLFormCollection::create.
Comment 21 808caaa4.8ce9.9cd6c799e9f6 2008-07-01 23:27:21 PDT
(In reply to comment #20)
I wonder if that isn't push esp....
Comment 22 Adam Roben (:aroben) 2008-07-02 10:34:18 PDT
I reverted the parts of r34432 that are relevant to HTMLFormCollection, and the bug no longer occurs. Here's the disassembly from a PGO build with part of r34432 reverted:

PassRefPtr<HTMLCollection> HTMLFormElement::elements()
{
00E09F20  push        ebp  
00E09F21  mov         ebp,esp 
00E09F23  sub         esp,14h 
00E09F26  push        ebx  
00E09F27  push        esi  
00E09F28  push        edi  
00E09F29  mov         dword ptr [ebp-14h],ecx 
    return new HTMLFormCollection(this);
00E09F2C  call        WTF::TCMalloc_ThreadCache::GetCache (0D80790h) 
00E09F31  push        20h  
00E09F33  mov         edi,eax 
00E09F35  call        WTF::ClassIndex (0DB72D0h) 
00E09F3A  movzx       esi,byte ptr WebCore::CSSStyleSelector::s_styleNotYetAvailable+54h (1213628h)[eax] 
00E09F41  mov         eax,dword ptr WebCore::CSSStyleSelector::s_styleNotYetAvailable+1D4h (12137A8h)[esi*4] 
00E09F48  pop         ecx  
00E09F49  lea         ebx,[edi+esi*8+0Ch] 
00E09F4D  mov         ecx,ebx 
00E09F4F  mov         dword ptr [ebp-8],eax 
00E09F52  call        WTF::RefPtr<KJS::SourceElements>::operator! (0E18310h) 
00E09F57  test        al,al 
00E09F59  jne         010A57DC 
00E09F5F  mov         eax,dword ptr [ebp-8] 
00E09F62  sub         dword ptr [edi],eax 
00E09F64  dec         word ptr [ebx+4] 
00E09F68  movzx       eax,word ptr [ebx+4] 
00E09F6C  cmp         ax,word ptr [ebx+6] 
00E09F70  jb          010A5840 
00E09F76  mov         edi,dword ptr [ebx] 
00E09F78  test        edi,edi 
00E09F7A  mov         eax,dword ptr [edi] 
00E09F7C  mov         dword ptr [ebx],eax 
00E09F7E  je          010A582D 
00E09F84  mov         eax,dword ptr [ebp-14h] 
00E09F87  test        eax,eax 
00E09F89  push        ecx  
00E09F8A  mov         dword ptr [esp],eax 
00E09F8D  je          WebCore::HTMLFormElement::elements+72h (0E09F92h) 
00E09F8F  inc         dword ptr [eax+4] 
00E09F92  call        WebCore::HTMLFormCollection::HTMLFormCollection (0E0E570h) 
00E09F97  test        eax,eax 
00E09F99  mov         ecx,dword ptr [ebp+8] 
00E09F9C  pop         edi  
00E09F9D  pop         esi  
00E09F9E  mov         dword ptr [ecx],eax 
00E09FA0  pop         ebx  
00E09FA1  je          WebCore::HTMLFormElement::elements+86h (0E09FA6h) 
00E09FA3  inc         dword ptr [eax+4] 
00E09FA6  mov         eax,ecx 
}
00E09FA8  leave            
00E09FA9  ret         4    
Comment 23 Adam Roben (:aroben) 2008-07-02 12:08:16 PDT
Disabling LTCG for just HTMLFormElement.cpp does not seem to fix the issue.
Comment 24 808caaa4.8ce9.9cd6c799e9f6 2008-07-02 14:33:49 PDT
(In reply to comment #23)
*At least*, HTMLFormCollection::create() has same problem.
With r34813,

mov     eax, [ebp+0Ch]
and     dword ptr [ebp+0Ch], 0
push    ecx ; PassRefPtr<>(form)
mov     edi, ecx ; edi is fastMalloced space
mov     [esp], eax
call    ??0HTMLFormCollection@WebCore... ; ctor

Oh, HTMLFormCollection::this and form cannot be same.

I wonder if 1st push ecx isn't push esp, again.

// btw, almost all fastMalloc() is inlined (by LTCG) ... is it desired??
// It's pretty large, for each, and may affect mem cache, I feel.
// I haven't check which is finally faster, inlined or not inlined.
Comment 25 808caaa4.8ce9.9cd6c799e9f6 2008-07-02 14:48:08 PDT
(In reply to comment #24. errata)
push    ecx ; *should be* PassRefPtr<>(form)
mov     edi, ecx ; ecx is fastMalloced space, edi should be _this for HTMLFormCollection
Comment 26 Mark Rowe (bdash) 2008-07-07 18:00:00 PDT
*** Bug 19934 has been marked as a duplicate of this bug. ***
Comment 27 Adam Roben (:aroben) 2008-07-09 09:51:42 PDT
*** Bug 19752 has been marked as a duplicate of this bug. ***
Comment 28 Adam Roben (:aroben) 2008-07-10 15:12:42 PDT
Turning off LTCG for all of WebCore fixes the crash. I now suspect that I wasn't building correctly when turning off LTCG for certain files previously.
Comment 29 Adam Roben (:aroben) 2008-07-10 15:52:03 PDT
(In reply to comment #23)
> Disabling LTCG for just HTMLFormElement.cpp does not seem to fix the issue.

Yes it does! You just have to actually get HTMLFormElement.cpp to rebuild!
Comment 30 Adam Roben (:aroben) 2008-07-10 15:55:49 PDT
Created attachment 22224 [details]
patch + changelog
Comment 31 Cameron Zwarich (cpst) 2008-07-10 15:57:53 PDT
Comment on attachment 22224 [details]
patch + changelog

r=me
Comment 32 Adam Roben (:aroben) 2008-07-10 15:59:40 PDT
Landed in r35105