179941 - XML-RPC response with an array of structs leaves element unretrievable vil GetElementAt

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Tony Wells]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

If an array of structs with the properties: there are exactly two array
elements, and the structs they contain have only one member, one of the elements
will return null when accessed via GetElementAt.

Read more details in the doc/details.txt file in the attachment.

Reproducible: Always

Steps to Reproduce:
The client and server are included, setup to produce the bug.

Check the console for dump output.
Actual Results:  
-*- xmlrpc-bugtest: Array row count: 2
-*- xmlrpc-bugtest: nsISupports?: [xpconnect wrapped nsISupports]
-*- xmlrpc-bugtest: likes: bobby
-*- xmlrpc-bugtest: nsISupports?: null


Expected Results:  
-*- xmlrpc-bugtest: Array row count: 2
-*- xmlrpc-bugtest: nsISupports?: [xpconnect wrapped nsISupports]
-*- xmlrpc-bugtest: likes: bobby
-*- xmlrpc-bugtest: nsISupports?: [xpconnect wrapped nsISupports]
_*_ xmlrpc-bugtest: likes: betty

If the number of rows in the array != 2, this bug doesn't seem to show up.

If the number of elements in the struct > 1, this bug doesn't seem to show up.

If Mozilla is running, and you create a new profile, then run the example
XUL file, the bug doesn't seem to show up.

I haven't done any regression testing, only checked up to an array of 10 structs
to see if the problem occurred for any other value than 2.  (It didn't)

The tarball has both the client and a PHP page for the server.  (Have to have
compiled PHP with --with-xmlrpc for the server page to work.)

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Samuel, could you please investigate and if this is a bug in the core XML
support reassign to me.

Comment 2

[Samuel Sieb]

This appears to be a timing issue.  The objects get created "late" somehow.

Comment 3

[Samuel Sieb]

Ok, here's a log of what happens.
The end of the parsing from onDataAvailable:
 -- XML-RPC client -- : Found result
 -- XML-RPC client -- : End element param
 -- XML-RPC client -- : End element params
 -- XML-RPC client -- : End element methodResponse
Now we get the onStopRequest with a description of what is being sent back to
the caller:
 -- XML-RPC client -- : Stop Request
 -- XML-RPC client -- : Parse finished
 -- XML-RPC client -- : Result: [xpconnect wrapped nsISupportsArray]
 -- XML-RPC client -- : first value is [xpconnect wrapped nsIDictionary]
Now the client:
-*- xmlrpc-bugtest: result is [xpconnect wrapped nsISupports]
Convert back to an array and let's see what we got (checking each item twice to
demonstrate the problem):
-*- xmlrpc-bugtest: result is [xpconnect wrapped nsISupportsArray]
-*- xmlrpc-bugtest: Array row count: 2
-*- xmlrpc-bugtest: aryElement(0) = null
-*- xmlrpc-bugtest: aryElement(0) = [xpconnect wrapped nsISupports]
-*- xmlrpc-bugtest: aryElement(1) = [xpconnect wrapped nsISupports]
-*- xmlrpc-bugtest: aryElement(1) = [xpconnect wrapped nsISupports]

Note that only the first check is null...  This is not 100% reproducible, but it
usually only takes a couple of tries.  I made it much more reproducible than it
was before by putting a delay right before calling the parser (in the xml-rpc
code). Putting a delay after calling the parser as well makes this apparently go
away again.

Comment 4

[Peter Van der Beken [:peterv]]

The XML-RPC component was removed (I think before Firefox 3).