[Bioc-devel] curious bug: maybe the R httpd help server interferes with XMLRPC?

[Paul Shannon]

Hi Duncan,

Thanks very much for finding the time to look at this.

Like you, I cannot reproduce the error.  I am creating a version of 64-bit windows version of XMLRPC which prints out the value of node whenever the function executes.  I hope that seeing the full text will shed light on where that text is coming from.

There's no compiled code in XMLRPC, right?  But libxml is compiled in your XML package?  I am trying to come up with candidates (however unlikely) for this architecture specific, windows 64-bit only, bug.

 - Paul

On Oct 28, 2010, at 8:30 AM, Duncan Temple Lang wrote:

> 
> Hi Paul
> 
> I have tried to replicate this on my OS X machine but cannot raise the error.
> (Replicating the creation of the Cytoscape window 40 times just leads to a Java heap
> error in Cytoscape.)
> 
> It appears to me that if you trap the error and look at the call stack when it occurs,
> we will be able to see from where the XML parser is being called and what the value
> of node is in the call
> 
>  convertToR(xmlParse(node, asText = TRUE))
> 
> So if you set
> 
>   options(error = recover)
> 
> you will see the traceback and be able to select the appropriate
> call frame and find the value of node.
> 
> 
> Your conjecture about the httpd server and XMLRPC interacting is possible.
> It could be through some horrendous and highly coincidental memory problem in C.
> It would be much more likely to happen, albeit it with low probability, if they are both
> using the same port - i.e. 9000.  Unless the user specifies the port, the httpd server picks a port
> at random, but that is between 10000 and 30000. I tried setting the help.ports option to 9000
> and then running the CytoscapeWindow() call, but that worked fine.
> 
> It is also "possible" that CytoscapeRPC is returning us HTML under some rare circumstance.
> 
> So the call stack and full contents of node should help us diagnose the problem properly.
> 
> 
>  D.
> 
> 
> 
> It is possible that Cytoscape and CytoscapeRPC
> 
> On 10/27/10 11:57 AM, Paul Shannon wrote:
>> A very odd bug was reported to me this morning.  Maybe somebody on this list will have some insight?
>> 
>> My hypothesis is far-fetched, but it seems to fit the evidence:  in some rare circumstances, messages to or from the R httpd help server get mingled in with the XMLRPC transmissions upon which RCytoscape depends.  The XMLRPC package, or the XML package upon which it depends, understandably balks when sent   <font> <br> and <p>
>> 
>> Key pieces of the user's bug report, running a thoroughly up-to-date R and bioc installation on Windows XP 64-bit, sp2, 12 GB Ram:
>> 
>>> library("RCytoscape")
>>> ?getGraph
>>  starting httpd help server ... done    # this might be significant.  I don't know what ports are used.
>> 
>>> ...  # create graphNEL, add nodes
>> 
>>> cw <- CytoscapeWindow ('vignette', graph=g)
>>   nodes have no label attribute -- adding default labels   # a normal warning from RCytoscape
>>   Entity 'nbsp' not defined                                # XMLRPC apparently sees ' '
>>   Entity 'nbsp' not defined
>>   Opening and ending tag mismatch: BR line 21 and font     # <br> <font>
>>   Opening and ending tag mismatch: BR line 20 and p        # <p>
>>   AttValue: " or ' expected
>>   Couldn't find end of Start Tag P line 25
>>   ...
>>   Premature end of data in tag body line 5
>>   Premature end of data in tag html line 1
>>   Error in convertToR(xmlParse(node, asText = TRUE)) :    # this line, and probably the preceeding lines, are  from the XMLRPC package
>>     error in evaluating the argument 'node' in selecting a method for function 'convertToR'
>> 
>> This looks for all the world like XML complaining about HTML.
>> 
>> I found this account of the httpd server (The R Journal Vol. 1/2, December 2009). 
>> 
>>   At a high level the goal of the server is to accept connections from browsers, convert each HTTP 
>>   request on a TCP/IP port into a call to an R function and deliver the result back to the browser.
>> 
>>   ... Instead, a general asynchronous server infrastructure had to be created which handles 
>>   multiple simultaneous connections and is yet able to synchronize them into synchronous 
>>   calls of the R evaluator. 
>> 
>> Does anyone have any insight into what might be going on here?   I've asked the gentleman who reported the bug to try again with no httpd help server running.
>> 
>> Thanks,
>> 
>> - Paul
>>