40231 - Crash from alternately sorting and changing XML form data (in js_UnlockRuntime)

Status: VERIFIED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[rwoods]

Per Eric Krock's request, I am re-reporting the crashing behavior originally 
noted in bug 32441 so that it can be tracked independently of the issue of data 
loss.

To cause the crash:

1. Go to http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7172
2. Place an 'x' in each of the two fields
3. Press toggle style button
4. Place a second 'x' immediately after the first in each of the two fields
5. Press toggle style button again

This is the stack crawl from Mac OS M16 nightly build ID: 2000052208:

PowerPC access exception at 17F1DE7C PR_Lock+00094
 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  17F907FC  
  080D7700    PPC  17F7C504  main+00140
  080D76A0    PPC  17F7B9C0  main1(int, char**, nsISupports*)+00944
  080D73E0    PPC  17C5418C  nsAppShellService::Run()+00018
  080D73A0    PPC  17AA918C  nsAppShell::Run()+00038
  080D7350    PPC  17AA9888  nsMacMessagePump::DoMessagePump()+0003C
  080D7300    PPC  17AA9E6C  nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00150
  080D72B0    PPC  17AC0E38  Repeater::DoIdlers(const EventRecord&)+00030
  080D7270    PPC  17AC1278  nsTimerPeriodical::IdleAction(const EventRecord&)+
00014
  080D7230    PPC  17AC1620  nsTimerPeriodical::FireNextReadyTimer()+0003C
  080D71F0    PPC  17AC143C  nsTimerPeriodical::FireAndReprimeTimer(nsTimerImpl*
)+00094
  080D71A0    PPC  17AC2134  nsTimerImpl::Fire()+00024
  080D7160    PPC  17CEDD9C  nsGlobalWindow_RunTimeout(nsITimer*, void*)+00018
  080D7120    PPC  17CED2F8  GlobalWindowImpl::RunTimeout(nsTimeoutImpl*)+00350
  080D6E60    PPC  17CD10B0  nsJSContext::CallEventHandler(void*, void*, unsigned 
int, void*,
 int*, int)+001E0
  080D6DA0    PPC  17EA24BC  JS_CallFunctionValue+00028
  080D6D60    PPC  17EBB734  js_InternalInvoke+000C0
  080D6CA0    PPC  17EBB500  js_Invoke+004C4
  080D6BC0    PPC  17EC196C  js_Interpret+05950
  080D6980    PPC  17ECC648  js_SetProperty+00804
  080D68C0    PPC  17EC4C18  js_LockObj+0002C
  080D6870    PPC  17EC4A78  js_LockScope1+00040
  
  Note that this is the latest nightly build (Mac OS M16 nightly build ID: 
2000052208), so the crashing problem has not been resolved.

Comment 1

[leger]

Adding crash keyword

Comment 2

[rwoods]

adding nsbeta2 keyword per Eric Krock's request

Comment 3

[leger]

What id the user exposure here?

Comment 4

[rwoods]

I'm not sure I understand the question. If the issue is "who cares", then the 
answer would be anyone completing an XML form where the XML layout might get 
changed during form completion. Also, although bug 32441 has now been marked 
invalid, the problem was not fixed, it simply "went away" on its own, further 
suggesting that some underlying problem with XML form data is unresolved and may 
resurface in ways that are more difficult to distill down to a 5 step test case 
(e.g, just intermittent unexplained crashes). Please note that bug 32441 was only 
ever confirmed on the Macintosh, so this may be a Macintosh only issue, but I 
wouldn't necessarily assume that this is the case.

Comment 5

[Andreas Franke (gone)]

Confirming bug. Reproduced on PC/Linux, build 2000052608. Changing Platform/OS
to All. Extending summary to include the name of crashing function. 
The stack trace is quite the same as on Mac:

#0  0x40113a98 in js_UnlockRuntime ()
#1  0x40113b91 in js_LockObj ()
#2  0x4011a96e in js_SetProperty ()
#3  0x40110bca in js_Interpret ()
#4  0x4010a9ea in js_Invoke ()
#5  0x4010abcc in js_InternalInvoke ()
#6  0x400f278f in JS_CallFunctionValue ()
#7  0x403d9b9e in nsJSContext::CallEventHandler ()

Comment 6

[rods (gone)]

this may be a dup of a bug you already had

Comment 7

[Michael La Guardia]

The question is how prevalent are XML forms on the web today.  Also, does this
affect HTML?

Comment 8

[Jim Roskind]

Declining beta2, please renominate if you have info that would change our minds

Comment 9

[waqar]

This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.

Comment 10

[waqar]

I am not able to type into the text fields. I am getting assertion in the
following file.
###!!! Break: at file nsXMLDocument.cpp, line 812
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: '(!((rv) &
0x80000000))', file nsXMLDocument.cpp, line 812

Comment 11

[waqar]

works for me with 2/23/2000 build

Comment 12

[ckritzer (gone)]

Marking VERIFIED WORKSFORME on:
- LinuxRH62 2000-09-08-08-M18 Commercial
- Win98     2000-09-08-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial