Bug 49667 – Crash in resetFormElementsOwner() when moving JIRA bug to another project

• Status: UNCONFIRMED
• Component: Forms

[Dimitris Apostolou]

Safari 5.0.2 (6533.18.5, r72146)
JIRA 4.1.2#531

Reproducibility: always

Steps:
1. Open an existing JIRA bug.
2. More Actions -> Move
3. Choose a different project and click on "Next" button.

What happened:
3. Crash.

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   ???                           	0x000000011a8c0c60 0 + 4740353120
1   com.apple.WebCore             	0x0000000100dce28e WebCore::Document::resetFormElementsOwner(WebCore::HTMLFormElement*) + 46
2   com.apple.WebCore             	0x0000000100d0077c WebCore::ContainerNode::removedFromDocument() + 76
3   com.apple.WebCore             	0x0000000100d0077c WebCore::ContainerNode::removedFromDocument() + 76
4   com.apple.WebCore             	0x0000000100d0077c WebCore::ContainerNode::removedFromDocument() + 76
5   com.apple.WebCore             	0x0000000100d03cbb void WebCore::Private::addChildNodesToDeletionQueue<WebCore::Node, WebCore::ContainerNode>(WebCore::Node*&, WebCore::Node*&, WebCore::ContainerNode*) + 107
6   com.apple.WebCore             	0x0000000100d03d7e void WebCore::removeAllChildrenInContainer<WebCore::Node, WebCore::ContainerNode>(WebCore::ContainerNode*) + 142
7   com.apple.WebCore             	0x0000000100ddcd13 WebCore::Document::removedLastRef() + 339
8   com.apple.WebCore             	0x0000000100ec2262 WebCore::DynamicNodeList::~DynamicNodeList() + 114
9   com.apple.WebCore             	0x00000001017cff9f WebCore::TagNodeList::~TagNodeList() + 127
10  com.apple.WebCore             	0x0000000101315faf WebCore::JSNodeList::~JSNodeList() + 239
11  com.apple.JavaScriptCore      	0x000000010079bc5c JSC::Heap::sweep() + 284
12  com.apple.JavaScriptCore      	0x000000010079e61b JSC::Heap::collectAllGarbage() + 75
13  com.apple.WebCore             	0x0000000100f58295 WebCore::collect(void*) + 21
14  com.apple.WebCore             	0x00000001017ec357 WebCore::ThreadTimers::sharedTimerFiredInternal() + 151
15  com.apple.WebCore             	0x00000001016f9f35 WebCore::timerFired(__CFRunLoopTimer*, void*) + 53
16  com.apple.CoreFoundation      	0x00007fff832c7be8 __CFRunLoopRun + 6488
17  com.apple.CoreFoundation      	0x00007fff832c5dbf CFRunLoopRunSpecific + 575
18  com.apple.HIToolbox           	0x00007fff8265991a RunCurrentEventLoopInMode + 333
19  com.apple.HIToolbox           	0x00007fff8265971f ReceiveNextEventCommon + 310
20  com.apple.HIToolbox           	0x00007fff826595d8 BlockUntilNextEventMatchingListInMode + 59
21  com.apple.AppKit              	0x00007fff87ffae64 _DPSNextEvent + 718
22  com.apple.AppKit              	0x00007fff87ffa7a9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
23  com.apple.Safari              	0x00000001000165d4 0x100000000 + 91604
24  com.apple.AppKit              	0x00007fff87fc048b -[NSApplication run] + 395
25  com.apple.AppKit              	0x00007fff87fb91a8 NSApplicationMain + 364
26  com.apple.Safari              	0x000000010000a4a0 0x100000000 + 42144

Expected result:
WebKit does not crash.

Notes:
Regression was introduced with r72146.

[Dimitris Apostolou]

Created attachment 74121 [details]
Crash log.

[Kenichi Ishibashi]

(In reply to comment #1)
> Created an attachment (id=74121) [details]
> Crash log.

Thank you for bug report. Is there any site could I reproduce this?

[Kenichi Ishibashi]

I tried some sites such as https://jira.springframework.org/ and http://jira.codehaus.org/ but there is no "Move" action. I guess I need the privilege to do it. I also tried http://sandbox.onjira.com/ but there is no "Move" action in "More Actions" menu, too. It seems that the action is no longer available in the version v4.2-b587#587-r130918, which is the site used. Is there other way to reproduce this?

[Alexey Proskuryakov]

Searching for "JIRA playground" returned <http://jira.sakaiproject.org/browse/JIRA>, which has v4.1.2#531. Perhaps it's reproducible there?

[Kenichi Ishibashi]

Hi Alexey,

(In reply to comment #4)
> Searching for "JIRA playground" returned <http://jira.sakaiproject.org/browse/JIRA>, which has v4.1.2#531. Perhaps it's reproducible there?

Thank you for the information. I created an account and logged in, then tried to find "Move" action in "More action" menu, but I can't find it, too. I think I need kind of permission to do the action.

[Dimitris Apostolou]

Unfortunately the JIRA instance I'm using belongs to private company and is not available to public.

Please note that the issue is reproducible only in JIRA 4.1.2 and not in latest JIRA 4.2

For example, http://jira.atlassian.com/ allows moving bugs around for fun but it doesn't occur there.

I would be happy to follow any advice on how to provide more info about the crash.

[Kenichi Ishibashi]

Hi Dimitris,

I've tried to guess the cause but I couldn't figure out it. Could you build WebKit with debug symbols and try this again? The stack trace including debug symbols on a crash may help us.

(In reply to comment #6)
> Unfortunately the JIRA instance I'm using belongs to private company and is not available to public.
> 
> Please note that the issue is reproducible only in JIRA 4.1.2 and not in latest JIRA 4.2
> 
> For example, http://jira.atlassian.com/ allows moving bugs around for fun but it doesn't occur there.
> 
> I would be happy to follow any advice on how to provide more info about the crash.

[Dimitris Apostolou]

Created attachment 74589 [details]
Attaching crash log from debug build.

[Kenichi Ishibashi]

Hi Dimitris,

Thanks the log. I couldn't reproduce the bug yet, even I tested the same environment (WebKit nightly build r72146 and JIRA 4.1.2#531). However, the log was helpful to guess the cause. I suspect that Node::document() might return NULL even the case. I'm not sure such the case could occur (and I couldn't reproduce the bug), but if you still have the problem, could you try the patch I'll post soon. This patch just removing referencing document(). As far as I investigated, the removed code doesn't make sense in any case so we can remove it without any regression.

(In reply to comment #8)
> Created an attachment (id=74589) [details]
> Attaching crash log from debug build.

[Kenichi Ishibashi]

Created attachment 74954 [details]
Patch

[Kenichi Ishibashi]

This patch is not for review because I couldn't reproduce the bug so I'm not sure this could solve the cause and there is no test.

(In reply to comment #10)
> Created an attachment (id=74954) [details]
> Patch

[Alexey Proskuryakov]

Node::document() can only return null for DocumentType nodes that aren't used with any Document yet. That's hardly the case here, so it's more likely that the node pointer itself is stale.

>  couldn't reproduce the bug yet, even I tested the same environment (WebKit nightly build r72146 and JIRA 4.1.2#531).

You can try to make the crash more likely in debug mode by adding ASSERT(fastMallocSize(this)) - pointers to unallocated memory would make fastMallocSize return 0.

[Dimitris Apostolou]

Funnily enough, I can't reproduce the bug anymore so I can't verify the fix...

I could reproduce it 100% and now it doesn't occur at all. Something must have changed in the JIRA configuration.

[Kenichi Ishibashi]

Hi Alexey,

Thanks for comment. It very helpful for me. I agree with you that Node::document() hardly returns null here, but the node pointer seems to be valid as far as I investigated the log. I added ASSERT(fastMallocSize(this)) and tried to reproduce but any assertion failure occurred.
 
(In reply to comment #12)
> Node::document() can only return null for DocumentType nodes that aren't used with any Document yet. That's hardly the case here, so it's more likely that the node pointer itself is stale.
> 
> >  couldn't reproduce the bug yet, even I tested the same environment (WebKit nightly build r72146 and JIRA 4.1.2#531).
> 
> You can try to make the crash more likely in debug mode by adding ASSERT(fastMallocSize(this)) - pointers to unallocated memory would make fastMallocSize return 0.

[Kenichi Ishibashi]

Hi Dimitris,

Thank you for response. So I'd like to leave this for now.

(In reply to comment #13)
> Funnily enough, I can't reproduce the bug anymore so I can't verify the fix...
> 
> I could reproduce it 100% and now it doesn't occur at all. Something must have changed in the JIRA configuration.

[Alexey Proskuryakov]

Not a P1, since this is not reproducible.