377276 - Problem with toString as described in bug 157797

Status: UNCONFIRMED

(Core :: XML, defect)

Description

[Remi Cool]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1) XPCOMViewer/0.9.5
Build Identifier: {37127241-1e6e-46aa-ba87-601d41bb47df}

The description of bug 157797 (https://bugzilla.mozilla.org/show_bug.cgi?id=157797) sais it all. 

"nsXmlRpcClient.js sometimes produces incorrect output in _generateArgumentBody
when invoking toString() of the wrapped primitive. Instead of a proper
request substring "<value><i4>50</i4></value>" we get
"<value><i4>[xpconnect wrapped nsISupportsPRInt32]</i4></value>" which
confuses the server."

In our application (running on XULRUNNER 1.8.0.4) we experienced this problem occasionally so it's probably not solved or has risen again. I included a patch which seems to help with no side effects.



Reproducible: Sometimes

Steps to Reproduce:
(from Bug 157797)

The following code works pretty much always:
---------------
1. var xmlRpc = Components.classes['@mozilla.org/xml-rpc/client;1']
.createInstance(Components.interfaces.nsIXmlRpcClient);
2. xmlRpc.init("some url");
3. var intParm=xmlRpc.createType(xmlRpc.INT, {});
4. intParm.data=Number(document.getElementById("someID").value);
5. xmlRpc.asyncCall(someListener, null, 'module.method', [intParm], 1);
---------------
_Rarely_ it will fail and the problem is not data-related. When it
does fail the problem is always in the invocation of toString()
method within nsXmlRpcClient.js. (NB: calling toString() from your code does work.)
Actual Results:  
"<value><i4>[xpconnect wrapped nsISupportsPRInt32]</i4></value>"

Expected Results:  
"<value><i4>50</i4></value>"

A put forward in Bug 157797 ... it looks like a race-condition.

Comment 1

[Remi Cool]

Attachment: Patch to fix the toString race-condition

Comment 2

[Remi Cool]

Attachment: nsXmlRpcClient.js with all my patches (368808, 368810, 377276)

Comment 3

[Remi Cool]

I'm currently testing the nsXmlRpcClient.js from the 1.9a4pre xulrunner package. I'll post back my findings on the problem I encountered in the 1.8.0.4 version.

Comment 4

[James Ross]

When making patches, you should use the unified diff format (e.g. "cvs diff -pu8") so that there is some reasonable context to look at.

Comment 5

[Samuel Sieb]

Wouldn't it be better to fix the race condition?  Does anyone have an idea what's happening?

Comment 6

[James Ross]

It would, but without a decent testcase or explanation I can't do that (as much as I'd love to).

Comment 7

[Remi Cool]

With version (1.39) from xulrunner 1.9a4pre, I still encounter the problem. 
After I applied the patch ... no more troubles (so far).

A testcase is a bit difficult. We have build a client application with xulrunner that communicates with an xml-rpc server (twisted). In cases when we fire a lot of xml-rpc requests (approx 50) in a very short timespan (as fast as we can click the send button), the race-condition pop's up. 

I will have to look into creating a simplefied testcase so that you can find out what's causing the race-condition. In the meantime, maybe it's better to include the patch until the race condition is dealt with.

Comment 8

[Samuel Sieb]

Remi, did you read all the comments in bug 157797?  The end conclusion was that there was no problem.  If you're firing so many requests at once, they are likely to overlap.  Are you sure they are all independent request objects, and are being handled properly?

Comment 9

[Remi Cool]

I can trigger/reproduce the problem sending many xml-rpc requests in a short timespan, but it occasionally pop's up with single requests too. 
 It's virtualy impossible to reproduce these single requests going wrong, because they occur randomly. Some day's you have 'em (a lot) and other day's it's fine. 

I've tested my code to be sure the requests are truly independent and as far as I can tell,  they are. For every request a new object is created that handles the request. This object contains all methods necessary to convert to and from XPCOM objects and process the request, callback and other stuff. 

With the patch in place, the problem is gone and it works flawlessly. If you do:

myString = '' + object;

The object is converted to a string ... so it's virtually the same as object.toString() or am I mistaken. 

There is definitely a problem somewhere :)

Comment 10

[James Ross]

You are correct that the suggested new code is (at least at a theoretical level) the same, as the JavaScreipt engine will call toString implicitly to convert the object.

There is indeed a problem somewhere, and my interest in this bug is for finding out the real bug and fixing it; I leave it to Samuel to decide if/when a/the workaround should be used.

I have tried running locally a few XML-RPC requests as described in comment 0, but as might be expected have had no luck in reproducing the issue.

One thing I have just spotted is that you are using both a distro-made browser version (Iceweasel) and a 64bit version. Is there any chance you could attempt to show whether the problem occurs on an official mozilla.org build? We need to try and eliminate as many possiblities as we can. :)