Apache OpenOffice (AOO) Bugzilla – Issue 56353
CVS diff: no output, return value 0
Last modified: 2006-08-30 08:56:42 UTC
Hi, today, Fri Oct 21 08:48:18 CEST 2005, somewhere between 08:00 and 08:20, there were problems with web (read: no web), with CVS (read: no CVS) etc. I had a tunnel running all over the night, messages there: pavel@paveljanik:~> OOo_tunnel Tunnel established. Type ctrl-c to exit. channel 2: open failed: connect failed: Connection timed out channel 3: open failed: connect failed: Connection refused channel 2: open failed: connect failed: Connection refused channel 2: open failed: connect failed: Connection refused channel 2: open failed: connect failed: Connection timed out channel 3: open failed: connect failed: Connection timed out channel 2: open failed: connect failed: Connection refused channel 2: open failed: connect failed: Connection refused I was building m135 and my build failed in sd/.../AccessibleSlideSorterView.cxx, thus I tried to see the diff between m134 and m135 with this command: pavel@paveljanik:~/.ooo/ooo_SRC680_m135_src/sd/source/ui/accessibility> cvs diff -r SRC680_m134 -r SRC680_m135 AccessibleSlideSorterView.cxx The result was *empty*, ie, no output *and* the return value (echo $?) was 0. I was fooled that there were no differences! But there were changes! (The file was updated after the first tagging and now it builds OK.)
we are dependent that cvs diff command produces correct results, please evaluate the root cause, these failures caused already a log of work.
Setting me on CC. Such behaviour is the worst I can imagine. We (to some degree) can live with complete CVS failure in form of 'connection refused', but giving no diffs also there are some and giving no error message about that can cramble complete childworkspaces when occuring during a cwsresync. Should we set priority to '1'?
Error just seen again. Hamburg RE is stopping all CWS integrations for now and informed our users to not resync any CWS. Prio 1!
adding moi to cc list
Are there any news on this? During the last hour I did not observ any CVS failure, but I still do not dare to perfrom critical tasks.
Working on the issue. I believe there is a similar issue filed https://sun-openofficeorg.extranet.collab.net/issues/show_bug.cgi?id=37 and I am following up that issue. Regards Karthik-Helpdesk
pavel, which version of cvs client have you used ?
The problem with this error is that it occurs only sporadically. But, when it occurs, probably all projects/modules are affected (at least I have seen it in dba/connectivity, dba/dbaccess, framework/sfx2, gsl/toolkit, gsl/vcl, graphics/svx, installation/scp2, sc/sc, util/officecfg, and util/svtools).
My CVS client is: pavel@linux:~> cvs --version Concurrent Versions System (CVS) 1.12.12 (client/server) ... stock SUSE Linux 9.3 version.
The root cause for this is a bug which is fixed in later releases. However since it will take some time for OO.o to be upgraded to that release, a patch will be available to fix this (for the current release). Engineering is already working on this.
Could you explain why the Prio has been changed from P1 to P2?
Stefan, It is unfortunate that IZ does not have a way to mark the severity as critical and instead only priority for the issue. For any issue, originally P1, if an adequate solution/workaround has been offered, we generally reduce the priority to allow other P1 issues to work on. By no means it is done to de- escalate the issue, since the internal issue is still set at the highest priority possible.
I agree with what you are saying about priorities and workarounds. Unfortunately I'm not aware of an adequate solution/workaround for this issue available to us.
An update on the engineering analysis of the problem (the root cause): ----- In CEE's XML-RPC module where this bug was traced to contain code which would slowly leak and cause incrementing a counter it kept for connection; eventually the counter reached a threshold and the code started refusing connections. CVS (and also IZ) interfaces (directly/indirectly) with this module and hence the outage occurs. The code is subsequently fixed in later versions. Unfortunately OO.o is running on 2.6.2 and will require a backport of this fix. ------------- A determination of the ETA of the patch will be made by Friday, 11, 2005.
It was decided to go ahead with the patch. Waiting to hear from engineering the estimate. I should not be more than couple of weeks.
The patch is now rolled out.
Reassigning back: - I have seen my problem only once, so it was "random", so I can't evaluate if the cause was fixed - I do nt know what was the primary cause of the problem anyway - I do not know what was in the patch - do you have diff, BTW? - I can't evaluate if that patch contained other (potentially buggy) fixes
Besides the spurious errors seen during a manual call of cvs diff the problem was experienced during scripted release engineering processes. I would agree to consider the issue as resolved. We will reopen as appropriate.
Closing this since no report of such errors any more. Please re-open if the error (rather no error) strikes back for CVS diff.
Haven't seen this for months, so I am closing the issue.