You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2013/06/17 21:22:35 UTC
Commit error using 1.8.0 final
I updated my Windows laptop to 1.8.0 final. I am trying to commit a
change for Subclipse to tigris.org and it is failing. The error
message is not that helpful. Any ideas how to get better error
information?
>svn ci -m "Post 1.10.0 release" trunk
Sending trunk\subclipse\org.tigris.subversion.clientadapter.javahl.feature\feature.xml
Sending trunk\subclipse\org.tigris.subversion.clientadapter.javahl.win64\META-INF\MANIFEST.MF
Adding (bin) trunk\www\update_1.10.x\artifacts.jar
Adding (bin) trunk\www\update_1.10.x\content.jar
Adding (bin) trunk\www\update_1.10.x\features\org.tigris.subversion.clientadapter.feature_1.10.0.jar
svn: E120106: Commit failed (details follow):
svn: E120106: Error running context: The server sent a truncated HTTP
response body.
> svn --version --verbose
svn, version 1.8.0 (r1490375)
compiled Jun 16 2013, 22:17:12 on x86-microsoft-windows5.1.2600
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
System information:
* running on x86/x86_64-microsoft-windows6.1.7601
- Windows 7 Professional, Service Pack 1, build 7601 [6.1 Client
Multiprocessor Free]
* linked dependencies:
- APR 1.4.6 (compiled with 1.4.6)
- APR-Util 1.5.1 (compiled with 1.5.1)
- SQLite 3.7.16.1 (static)
* loaded shared libraries:
- C:\Program Files (x86)\CollabNet\Subversion Client\svn.exe (1.8.0.48583)
- C:\Windows\SysWOW64\ntdll.dll (6.1.7601.17725)
- C:\Windows\syswow64\kernel32.dll (6.1.7601.18015)
- C:\Windows\syswow64\KERNELBASE.dll (6.1.7601.18015)
- C:\Windows\SysWOW64\SYSFER.DLL (12.1.2015.2015)
- C:\Program Files (x86)\CollabNet\Subversion Client\libapr-1.dll (1.4.6)
- C:\Windows\syswow64\WS2_32.dll (6.1.7601.17514)
- C:\Windows\syswow64\msvcrt.dll (7.0.7601.17744)
- C:\Windows\syswow64\RPCRT4.dll (6.1.7601.17514)
- C:\Windows\syswow64\SspiCli.dll (6.1.7601.17940)
- C:\Windows\syswow64\CRYPTBASE.dll (6.1.7600.16385)
- C:\Windows\SysWOW64\sechost.dll (6.1.7600.16385)
- C:\Windows\syswow64\NSI.dll (6.1.7600.16385)
- C:\Windows\system32\MSWSOCK.dll (6.1.7601.17514)
- C:\Windows\syswow64\user32.dll (6.1.7601.17514)
- C:\Windows\syswow64\GDI32.dll (6.1.7601.17514)
- C:\Windows\syswow64\LPK.dll (6.1.7600.16385)
- C:\Windows\syswow64\USP10.dll (1.626.7601.18009)
- C:\Windows\syswow64\ADVAPI32.dll (6.1.7601.17514)
- C:\Windows\syswow64\SHELL32.dll (6.1.7601.18103)
- C:\Windows\syswow64\SHLWAPI.dll (6.1.7601.17514)
- C:\Program Files (x86)\CollabNet\Subversion Client\MSVCR100.dll
(10.0.40219.325)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libsvn_client-1.dll (1.8.0.48583)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libsvn_delta-1.dll (1.8.0.48583)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libaprutil-1.dll (1.5.1)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libapriconv-1.dll (1.2.1)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libsvn_subr-1.dll (1.8.0.48583)
- C:\Windows\system32\SHFOLDER.dll (6.1.7600.16385)
- C:\Windows\syswow64\ole32.dll (6.1.7601.17514)
- C:\Windows\syswow64\CRYPT32.dll (6.1.7601.18151)
- C:\Windows\syswow64\MSASN1.dll (6.1.7601.17514)
- C:\Windows\system32\VERSION.dll (6.1.7600.16385)
- C:\Windows\syswow64\PSAPI.DLL (6.1.7600.16385)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libsvn_diff-1.dll (1.8.0.48583)
- C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_ra-1.dll
(1.8.0.48583)
- C:\Program Files (x86)\CollabNet\Subversion Client\LIBEAY32.dll (1.0.1.5)
- C:\Program Files (x86)\CollabNet\Subversion Client\SSLEAY32.dll (1.0.1.5)
- C:\Windows\system32\Secur32.dll (6.1.7601.17940)
- C:\Program Files (x86)\CollabNet\Subversion Client\libsasl.dll (2.1.23)
- C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_fs-1.dll
(1.8.0.48583)
- C:\Program Files (x86)\CollabNet\Subversion
Client\libsvn_repos-1.dll (1.8.0.48583)
- C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_wc-1.dll
(1.8.0.48583)
- C:\Windows\system32\IMM32.DLL (6.1.7601.17514)
- C:\Windows\syswow64\MSCTF.dll (6.1.7600.16385)
- C:\Windows\system32\profapi.dll (6.1.7600.16385)
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Tue, Jun 18, 2013 at 1:33 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
>> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>>> change for Subclipse to tigris.org and it is failing. The error
>>> message is not that helpful. Any ideas how to get better error
>>> information?
>>
>> There might be a higher level option, but in serf you can enable lots
>> of debug logging, at compile time in serf_private.h.
>> SSL_VERBOSE gives huge amount of log lines but is probably what you
>> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
>
> I sent Lieven a tcpdump. Hopefully that will help. In the meantime I
> found another tool that analyzes HTTP traffic. The last request
> before it fails is a DELETE request that the server responds with a
> 204. Would that be unexpected by Serf?
The DELETE is sent in the abort_edit callback (commit.c), so I suppose
that's in reaction of ra_serf receiving the error from serf when
reading the response.
> The URL for the DELETE request is:
>
> http://subclipse.tigris.org/svn/subclipse/!svn/act/b61b1e79-ba56-41b3-8b07-8649146e8212
>
> Right before that (maybe Serf has multiple connections going) is a
ra_serf uses only one serf connection in parallel for commit, but that
can manage multiple consecutive TCP connections.
> CHECKOUT that gets a 201. I notice that one says it was Closed by
> peer, so that might be the problem.
The error you see is SERF_ERROR_TRUNCATED_HTTP_RESPONSE. This is only
returned by serf in case of a response that's missing data, e.g. a
chunk that's too short or missing compressed bytes.
If the server closes the connection, it should have added the
"Connection: Close" header on the last response. Then serf will handle
this gracefully.
Lieven
> Here is the info I can get out of
> this tool:
>
> Request Headers:
>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/depth,http://subversion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops
> Transfer-Encoding: chunked
> User-Agent: SVN/1.8.0 (x86_64-apple-darwin11.4.2) serf/1.2.1
> Accept-Encoding: gzip
> Content-Type: text/xml
> Authorization: Basic xxxxxx
> Host: subclipse.tigris.org
>
> Response Headers:
>
> Server: Apache
> HelmLoginID: markphip
> Location: http://subclipse.tigris.org/svn/subclipse/!svn/wrk/b61b1e79-ba56-41b3-8b07-8649146e8212/trunk/www/update_1.10.x/features
> Cache-Control: no-cache
> Content-Type: text/html; charset=ISO-8859-1
> Content-Length: 349
> Date: Mon, 17 Jun 2013 23:22:39 GMT
>
> POST Text:
>
> <?xml version="1.0" encoding="utf-8"?><D:checkout
> xmlns:D="DAV:"><D:activity-set><D:href>/svn/subclipse/!svn/act/b61b1e79-ba56-41b3-8b07-8649146e8212</D:href></D:activity-set><D:apply-to-version></D:apply-to-version></D:checkout>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Mark Phippard <ma...@gmail.com>.
I won't be online for another hour or so. Could someone try committing to Tigris using 1.8? Maybe all commits to that server fail?
Our subversion project has a repos. Just commit outside the www folder.
Sent from my iPhone
On Jun 18, 2013, at 7:11 AM, Philip Martin <ph...@wandisco.com> wrote:
> Ivan Zhakov <iv...@visualsvn.com> writes:
>
>> On Tue, Jun 18, 2013 at 9:55 AM, Ben Reser <be...@reser.org> wrote:
>>>
>>> The 204 shouldn't be odd, that just means a response without content.
>> Most likely serf doesn't handle HTTP 204 response code and expect
>> message body, while server doesn't send it.
>
> A 204 response is the normal behaviour after just about every failed
> commit, serf doesn't have a problem on my Linux box:
>
> $ svn ci -mm wc
> Sending wc/A/f
> Transmitting file data .svn: E155011: Commit failed (details follow):
> svn: E155011: File '/home/pm/sw/subversion/obj/wc/A/f' is out of date
> svn: E170004: Item '/A/f' is out of date
>
> DELETE /obj/repo/!svn/txn/2-3 HTTP/1.1\r
> Host: localhost:9630\r
> User-Agent: SVN/1.8.1-dev (x86_64-unknown-linux-gnu) serf/1.2.1\r
> DAV: http://subversion.tigris.org/xmlns/dav/svn/depth\r
> DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo\r
> DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops\r
> \r
>
> HTTP/1.1 204 No Content\r
> Date: Tue, 18 Jun 2013 11:04:35 GMT\r
> Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.9.0-dev\r
> Content-Length: 0\r
> Content-Type: text/plain\r
> \r
>
>
>
> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
> www.wandisco.com
Re: Commit error using 1.8.0 final
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@visualsvn.com> writes:
> On Tue, Jun 18, 2013 at 9:55 AM, Ben Reser <be...@reser.org> wrote:
>>
>> The 204 shouldn't be odd, that just means a response without content.
>>
> Most likely serf doesn't handle HTTP 204 response code and expect
> message body, while server doesn't send it.
A 204 response is the normal behaviour after just about every failed
commit, serf doesn't have a problem on my Linux box:
$ svn ci -mm wc
Sending wc/A/f
Transmitting file data .svn: E155011: Commit failed (details follow):
svn: E155011: File '/home/pm/sw/subversion/obj/wc/A/f' is out of date
svn: E170004: Item '/A/f' is out of date
DELETE /obj/repo/!svn/txn/2-3 HTTP/1.1\r
Host: localhost:9630\r
User-Agent: SVN/1.8.1-dev (x86_64-unknown-linux-gnu) serf/1.2.1\r
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth\r
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo\r
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops\r
\r
HTTP/1.1 204 No Content\r
Date: Tue, 18 Jun 2013 11:04:35 GMT\r
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.9.0-dev\r
Content-Length: 0\r
Content-Type: text/plain\r
\r
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Re: Commit error using 1.8.0 final
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, Jun 18, 2013 at 9:55 AM, Ben Reser <be...@reser.org> wrote:
> On Tue, Jun 18, 2013 at 1:33 AM, Mark Phippard <ma...@gmail.com> wrote:
>> I sent Lieven a tcpdump. Hopefully that will help. In the meantime I
>> found another tool that analyzes HTTP traffic. The last request
>> before it fails is a DELETE request that the server responds with a
>> 204. Would that be unexpected by Serf?
>>
>> The URL for the DELETE request is:
>>
>> http://subclipse.tigris.org/svn/subclipse/!svn/act/b61b1e79-ba56-41b3-8b07-8649146e8212
>
> The 204 shouldn't be odd, that just means a response without content.
>
Most likely serf doesn't handle HTTP 204 response code and expect
message body, while server doesn't send it. Quoting RFC 2616 [1]:
[[[
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
]]]
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: Commit error using 1.8.0 final
Posted by Ben Reser <be...@reser.org>.
On Tue, Jun 18, 2013 at 1:33 AM, Mark Phippard <ma...@gmail.com> wrote:
> I sent Lieven a tcpdump. Hopefully that will help. In the meantime I
> found another tool that analyzes HTTP traffic. The last request
> before it fails is a DELETE request that the server responds with a
> 204. Would that be unexpected by Serf?
>
> The URL for the DELETE request is:
>
> http://subclipse.tigris.org/svn/subclipse/!svn/act/b61b1e79-ba56-41b3-8b07-8649146e8212
The 204 shouldn't be odd, that just means a response without content.
However, the fact that you have requests happening after a DELETE
request seems odd. This particular DELETE is a activity URL, which
means it is removing the transaction on the server. If for some
reason we're sending this DELETE before we finish sending the other
requests that need to be sent for the commit, that would obviously be
very bad.
Are you sure the DELETE request is not happening after the failure?
Because it would be normal for the client to send DELETE after it
encountered some problem.
> Right before that (maybe Serf has multiple connections going) is a
> CHECKOUT that gets a 201. I notice that one says it was Closed by
> peer, so that might be the problem. Here is the info I can get out of
> this tool:
Possible the client/serf thinks the checkout fails due to whatever is
causing that "Closed by peer" you're seeing, which would trigger error
and the DELETE. Hard to say what any traffic after the DELETE is
without knowing more than you posted on the list.
Re: Commit error using 1.8.0 final
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>> change for Subclipse to tigris.org and it is failing. The error
>> message is not that helpful. Any ideas how to get better error
>> information?
>
> There might be a higher level option, but in serf you can enable lots
> of debug logging, at compile time in serf_private.h.
> SSL_VERBOSE gives huge amount of log lines but is probably what you
> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
I sent Lieven a tcpdump. Hopefully that will help. In the meantime I
found another tool that analyzes HTTP traffic. The last request
before it fails is a DELETE request that the server responds with a
204. Would that be unexpected by Serf?
The URL for the DELETE request is:
http://subclipse.tigris.org/svn/subclipse/!svn/act/b61b1e79-ba56-41b3-8b07-8649146e8212
Right before that (maybe Serf has multiple connections going) is a
CHECKOUT that gets a 201. I notice that one says it was Closed by
peer, so that might be the problem. Here is the info I can get out of
this tool:
Request Headers:
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth,http://subversion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked
User-Agent: SVN/1.8.0 (x86_64-apple-darwin11.4.2) serf/1.2.1
Accept-Encoding: gzip
Content-Type: text/xml
Authorization: Basic xxxxxx
Host: subclipse.tigris.org
Response Headers:
Server: Apache
HelmLoginID: markphip
Location: http://subclipse.tigris.org/svn/subclipse/!svn/wrk/b61b1e79-ba56-41b3-8b07-8649146e8212/trunk/www/update_1.10.x/features
Cache-Control: no-cache
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 349
Date: Mon, 17 Jun 2013 23:22:39 GMT
POST Text:
<?xml version="1.0" encoding="utf-8"?><D:checkout
xmlns:D="DAV:"><D:activity-set><D:href>/svn/subclipse/!svn/act/b61b1e79-ba56-41b3-8b07-8649146e8212</D:href></D:activity-set><D:apply-to-version></D:apply-to-version></D:checkout>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jun 18, 2013 at 10:29 AM, Paul Burba <pt...@gmail.com> wrote:
> On Tue, Jun 18, 2013 at 10:16 AM, Paul Burba <pt...@gmail.com> wrote:
>> On Tue, Jun 18, 2013 at 9:20 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
>>>> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>>>>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>>>>> change for Subclipse to tigris.org and it is failing. The error
>>>>> message is not that helpful. Any ideas how to get better error
>>>>> information?
>>>>
>>>> There might be a higher level option, but in serf you can enable lots
>>>> of debug logging, at compile time in serf_private.h.
>>>> SSL_VERBOSE gives huge amount of log lines but is probably what you
>>>> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
>>>
>>> I turned on everything and ran command again. Attaching the output.
>>>
>>> I also created a test project on tigris. So far, all commits are
>>> working for that project -- which I guess is good news. Maybe some
>>> odd scenario I am running into.
>>
>> Getting somewhere on this...
>>
>> I tried to commit some text changes and added binaries to a tigris
>> sandbox and saw no problems:
>>
>> C:\SVN\tigris-sandbox>svn ci -m "Text changes and added binaries"
>> Sending DIR-A\DIR-B\authors.xml
>> Sending DIR-A\DIR-B\build.xml
>> Adding (bin) DIR-A\DIR-C\authz_tests.pyc
>> Adding (bin) DIR-A\DIR-C\autoprop_tests.pyc
>> Adding (bin) DIR-A\DIR-C\basic_tests.pyc
>> Adding (bin) DIR-A\DIR-C\blame_tests.pyc
>> Adding (bin) DIR-A\DIR-C\javaws.jar
>> Adding (bin) DIR-A\DIR-C\jce.jar
>> Adding (bin) DIR-A\DIR-C\jfr.jar
>> Adding (bin) DIR-A\DIR-C\svn.exe
>> Transmitting file data ..........
>> Committed revision 5.
>>
>> That was with a debug build. Then I tried a release build and sure
>> enough, I see the problem Mark reported:
>>
>> C:\SVN\tigris-sandbox>svn ci -m "1.8 Release build (yeah, this is a
>> shot in the dark) text mods and added binaries"
>> Adding (bin) DIR-A\DIR-C\__init__ - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\authz_tests - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\autoprop_tests - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\basic_tests - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\blame_tests - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\ezt - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\gen_base - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\gen_vcnet_vcproj - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\gen_win - Copy.pyc
>> Adding (bin) DIR-A\DIR-C\javaws - Copy.jar
>> Adding (bin) DIR-A\DIR-C\jce - Copy.jar
>> Adding (bin) DIR-A\DIR-C\jfr - Copy.jar
>> Adding (bin) DIR-A\DIR-C\svn - Copy.exe
>> Sending foo.txt
>> svn: E120106: Commit failed (details follow):
>> svn: E120106: Error running context: The server sent a truncated HTTP
>> response body.
>>
>> Can anyone confirm they are seeing similar differences between release
>> and debug builds?
>
> False alarm. While testing some more to check that this error
> consistently occurred, it stopped and I was able to commit with a
> release build several times.
Definitely a false alarm; I just got the failure with a debug build.
Sorry for the noise.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Commit error using 1.8.0 final
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jun 18, 2013 at 10:16 AM, Paul Burba <pt...@gmail.com> wrote:
> On Tue, Jun 18, 2013 at 9:20 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
>>> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>>>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>>>> change for Subclipse to tigris.org and it is failing. The error
>>>> message is not that helpful. Any ideas how to get better error
>>>> information?
>>>
>>> There might be a higher level option, but in serf you can enable lots
>>> of debug logging, at compile time in serf_private.h.
>>> SSL_VERBOSE gives huge amount of log lines but is probably what you
>>> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
>>
>> I turned on everything and ran command again. Attaching the output.
>>
>> I also created a test project on tigris. So far, all commits are
>> working for that project -- which I guess is good news. Maybe some
>> odd scenario I am running into.
>
> Getting somewhere on this...
>
> I tried to commit some text changes and added binaries to a tigris
> sandbox and saw no problems:
>
> C:\SVN\tigris-sandbox>svn ci -m "Text changes and added binaries"
> Sending DIR-A\DIR-B\authors.xml
> Sending DIR-A\DIR-B\build.xml
> Adding (bin) DIR-A\DIR-C\authz_tests.pyc
> Adding (bin) DIR-A\DIR-C\autoprop_tests.pyc
> Adding (bin) DIR-A\DIR-C\basic_tests.pyc
> Adding (bin) DIR-A\DIR-C\blame_tests.pyc
> Adding (bin) DIR-A\DIR-C\javaws.jar
> Adding (bin) DIR-A\DIR-C\jce.jar
> Adding (bin) DIR-A\DIR-C\jfr.jar
> Adding (bin) DIR-A\DIR-C\svn.exe
> Transmitting file data ..........
> Committed revision 5.
>
> That was with a debug build. Then I tried a release build and sure
> enough, I see the problem Mark reported:
>
> C:\SVN\tigris-sandbox>svn ci -m "1.8 Release build (yeah, this is a
> shot in the dark) text mods and added binaries"
> Adding (bin) DIR-A\DIR-C\__init__ - Copy.pyc
> Adding (bin) DIR-A\DIR-C\authz_tests - Copy.pyc
> Adding (bin) DIR-A\DIR-C\autoprop_tests - Copy.pyc
> Adding (bin) DIR-A\DIR-C\basic_tests - Copy.pyc
> Adding (bin) DIR-A\DIR-C\blame_tests - Copy.pyc
> Adding (bin) DIR-A\DIR-C\ezt - Copy.pyc
> Adding (bin) DIR-A\DIR-C\gen_base - Copy.pyc
> Adding (bin) DIR-A\DIR-C\gen_vcnet_vcproj - Copy.pyc
> Adding (bin) DIR-A\DIR-C\gen_win - Copy.pyc
> Adding (bin) DIR-A\DIR-C\javaws - Copy.jar
> Adding (bin) DIR-A\DIR-C\jce - Copy.jar
> Adding (bin) DIR-A\DIR-C\jfr - Copy.jar
> Adding (bin) DIR-A\DIR-C\svn - Copy.exe
> Sending foo.txt
> svn: E120106: Commit failed (details follow):
> svn: E120106: Error running context: The server sent a truncated HTTP
> response body.
>
> Can anyone confirm they are seeing similar differences between release
> and debug builds?
False alarm. While testing some more to check that this error
consistently occurred, it stopped and I was able to commit with a
release build several times.
> --
> Paul T. Burba
> CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
> Skype: ptburba
>
>> I am just committing some new files though, so not sure what I am
>> doing that would be "weird".
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Commit error using 1.8.0 final
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jun 18, 2013 at 9:20 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
>> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>>> change for Subclipse to tigris.org and it is failing. The error
>>> message is not that helpful. Any ideas how to get better error
>>> information?
>>
>> There might be a higher level option, but in serf you can enable lots
>> of debug logging, at compile time in serf_private.h.
>> SSL_VERBOSE gives huge amount of log lines but is probably what you
>> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
>
> I turned on everything and ran command again. Attaching the output.
>
> I also created a test project on tigris. So far, all commits are
> working for that project -- which I guess is good news. Maybe some
> odd scenario I am running into.
Getting somewhere on this...
I tried to commit some text changes and added binaries to a tigris
sandbox and saw no problems:
C:\SVN\tigris-sandbox>svn ci -m "Text changes and added binaries"
Sending DIR-A\DIR-B\authors.xml
Sending DIR-A\DIR-B\build.xml
Adding (bin) DIR-A\DIR-C\authz_tests.pyc
Adding (bin) DIR-A\DIR-C\autoprop_tests.pyc
Adding (bin) DIR-A\DIR-C\basic_tests.pyc
Adding (bin) DIR-A\DIR-C\blame_tests.pyc
Adding (bin) DIR-A\DIR-C\javaws.jar
Adding (bin) DIR-A\DIR-C\jce.jar
Adding (bin) DIR-A\DIR-C\jfr.jar
Adding (bin) DIR-A\DIR-C\svn.exe
Transmitting file data ..........
Committed revision 5.
That was with a debug build. Then I tried a release build and sure
enough, I see the problem Mark reported:
C:\SVN\tigris-sandbox>svn ci -m "1.8 Release build (yeah, this is a
shot in the dark) text mods and added binaries"
Adding (bin) DIR-A\DIR-C\__init__ - Copy.pyc
Adding (bin) DIR-A\DIR-C\authz_tests - Copy.pyc
Adding (bin) DIR-A\DIR-C\autoprop_tests - Copy.pyc
Adding (bin) DIR-A\DIR-C\basic_tests - Copy.pyc
Adding (bin) DIR-A\DIR-C\blame_tests - Copy.pyc
Adding (bin) DIR-A\DIR-C\ezt - Copy.pyc
Adding (bin) DIR-A\DIR-C\gen_base - Copy.pyc
Adding (bin) DIR-A\DIR-C\gen_vcnet_vcproj - Copy.pyc
Adding (bin) DIR-A\DIR-C\gen_win - Copy.pyc
Adding (bin) DIR-A\DIR-C\javaws - Copy.jar
Adding (bin) DIR-A\DIR-C\jce - Copy.jar
Adding (bin) DIR-A\DIR-C\jfr - Copy.jar
Adding (bin) DIR-A\DIR-C\svn - Copy.exe
Sending foo.txt
svn: E120106: Commit failed (details follow):
svn: E120106: Error running context: The server sent a truncated HTTP
response body.
Can anyone confirm they are seeing similar differences between release
and debug builds?
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
> I am just committing some new files though, so not sure what I am
> doing that would be "weird".
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 5, 2013 at 1:48 PM, Lieven Govaerts <lg...@apache.org> wrote:
> On Wed, Jun 19, 2013 at 11:26 AM, Joe Orton <jo...@redhat.com> wrote:
>> On Tue, Jun 18, 2013 at 06:32:13PM +0200, Lieven Govaerts wrote:
>>> This 204 response is not a problem, there's a special case for
>>> Content-Length == 0 && code == 204 in serf (response_buckets.c).
>>
>> Looking at the serf (1.2.1) code, that logic isn't right, you need to
>> follow the precedence in the RFC, particularly that [23]04 is dominant
>> over C-L/T-E in determining message length. (I don't know whether that
>> bug could manifest exactly as described here.)
>>
>> http://tools.ietf.org/html/rfc2616#section-4.4
>
> You're right, that code was not completely aligned with RFC2616. Fixed
> on serf trunk in r2011 and r2012.
>
> That can't explain this particular issue though, the 204 response had
> Content-Length 0, so serf should have done the right thing. It was the
> "201 Created" with Content-Length 349 that lacked the message body.
>
> Mark: is this still an open issue?
Do you mean if I were to use the latest Serf and SVN trunk?
Once I came up with the reproduction recipe that I gave you and Mike,
I have not done anything. I have been using SVN 1.7 until I hear that
it is fixed. I will certainly try again when 1.8.1 and Serf releases
are available to try it with.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Lieven Govaerts <lg...@apache.org>.
On Wed, Jun 19, 2013 at 11:26 AM, Joe Orton <jo...@redhat.com> wrote:
> On Tue, Jun 18, 2013 at 06:32:13PM +0200, Lieven Govaerts wrote:
>> This 204 response is not a problem, there's a special case for
>> Content-Length == 0 && code == 204 in serf (response_buckets.c).
>
> Looking at the serf (1.2.1) code, that logic isn't right, you need to
> follow the precedence in the RFC, particularly that [23]04 is dominant
> over C-L/T-E in determining message length. (I don't know whether that
> bug could manifest exactly as described here.)
>
> http://tools.ietf.org/html/rfc2616#section-4.4
You're right, that code was not completely aligned with RFC2616. Fixed
on serf trunk in r2011 and r2012.
That can't explain this particular issue though, the 204 response had
Content-Length 0, so serf should have done the right thing. It was the
"201 Created" with Content-Length 349 that lacked the message body.
Mark: is this still an open issue?
> Regards, Joe
thanks,
Lieven
Re: Commit error using 1.8.0 final
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jun 18, 2013 at 06:32:13PM +0200, Lieven Govaerts wrote:
> This 204 response is not a problem, there's a special case for
> Content-Length == 0 && code == 204 in serf (response_buckets.c).
Looking at the serf (1.2.1) code, that logic isn't right, you need to
follow the precedence in the RFC, particularly that [23]04 is dominant
over C-L/T-E in determining message length. (I don't know whether that
bug could manifest exactly as described here.)
http://tools.ietf.org/html/rfc2616#section-4.4
Regards, Joe
Re: Commit error using 1.8.0 final
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Tue, Jun 18, 2013 at 3:20 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
>> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>>> change for Subclipse to tigris.org and it is failing. The error
>>> message is not that helpful. Any ideas how to get better error
>>> information?
>>
>> There might be a higher level option, but in serf you can enable lots
>> of debug logging, at compile time in serf_private.h.
>> SSL_VERBOSE gives huge amount of log lines but is probably what you
>> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
>
> I turned on everything and ran command again. Attaching the output.
>
Extract from the debugging output:
> [2013-06-18T09:17:40.050463-04] [l:204.11.125.145:65477 r:204.16.104.146:80] ./outgoing.c: --- socket_sendv:
> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x/features HTTP/1.1
> Host: subclipse.tigris.org
> Authorization: Basic xxxxxxxxxxxxxxxxxx
> User-Agent: SVN/1.8.0 (x86_64-apple-darwin11.4.2) serf/1.2.1
> Content-Type: text/xml
> Accept-Encoding: gzip
> DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
> DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
> DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
> Transfer-Encoding: chunked
>
> e5
> <?xml version="1.0" encoding="utf-8"?><D:checkout xmlns:D="DAV:"><D:activity-set><D:href>/svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-> 5be2e0291f8e</D:href></D:activity-set><D:apply-to-version></D:apply-to-version></D:checkout>
> 0
>
> -(703)-
> [2013-06-18T09:17:40.171850-04] [l:204.11.125.145:65477 r:204.16.104.146:80] buckets/socket_buckets.c: --- socket_recv:
> HTTP/1.1 201 Created
> Date: Tue, 18 Jun 2013 13:17:37 GMT
> Server: Apache
> HelmLoginID: markphip
> Cache-Control: no-cache
> Location: http://subclipse.tigris.org/svn/subclipse/!svn/wrk/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e/trunk/www/update_1.10.x/features
> Content-Length: 349
> Content-Type: text/html; charset=ISO-8859-1
>
>
> -(323)-
> [2013-06-18T09:17:40.173550-04] [l:204.11.125.145:65477 r:204.16.104.146:80] buckets/socket_buckets.c: socket_recv error 70014
This response has content-length:349 yet no data is received in the
response body. Serf then gets an APR_EOF on the socket.
So basically seen from the client, the server aborts the connection
mid-response unexpectedly. Not even a Connection:Close header was set.
Can you verify in your wireshark trace that you see the same thing as
what's logged?
The question here is why the server aborts the connection.
> [2013-06-18T09:17:41.021136-04] [l:204.11.125.145:65477 r:204.16.104.146:80] ./outgoing.c: closed socket, status 0
> [2013-06-18T09:17:41.021182-04] ./outgoing.c: reset connection 0x588d4a28
> [2013-06-18T09:17:41.021217-04] ./outgoing.c: created socket for conn 0x588d4a28, status 0
> [2013-06-18T09:17:41.021301-04] [l:204.11.125.145:65478 r:204.16.104.146:80] ./outgoing.c: connected socket for conn 0x588d4a28, status 36
> [2013-06-18T09:17:41.149533-04] [l:204.11.125.145:65478 r:204.16.104.146:80] ./outgoing.c: --- socket_sendv:
> DELETE /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
> Host: subclipse.tigris.org
..
> HTTP/1.1 204 No Content
> Date: Tue, 18 Jun 2013 13:17:38 GMT
> Server: Apache
> HelmLoginID: markphip
> Content-Length: 0
> Content-Type: text/plain
>
>
> -(148)-
This 204 response is not a problem, there's a special case for
Content-Length == 0 && code == 204 in serf (response_buckets.c).
> I also created a test project on tigris. So far, all commits are
> working for that project -- which I guess is good news. Maybe some
> odd scenario I am running into.
>
> I am just committing some new files though, so not sure what I am
> doing that would be "weird".
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
hth,
Lieven
Re: Commit error using 1.8.0 final
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/18/2013 10:42 AM, Mark Phippard wrote:
>> Might there possibly be an HTTP/1.0 proxy at work here?
>
> If there is, it would have to be on tigris itself. Mike Pilato could
> probably answer that better. I think it is mostly a plain (although
> old) Apache + SVN. The authentication and authorization stuff is
> custom. I do not think there is any proxy involved.
To my knowledge there is no proxy involved here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Commit error using 1.8.0 final
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jun 18, 2013 at 10:38 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 18.06.2013 16:34, Mark Phippard wrote:
>> On Tue, Jun 18, 2013 at 10:25 AM, Philip Martin
>> <ph...@wandisco.com> wrote:
>>> Mark Phippard <ma...@gmail.com> writes:
>>>
>>>> I also created a test project on tigris. So far, all commits are
>>>> working for that project -- which I guess is good news. Maybe some
>>>> odd scenario I am running into.
>>>>
>>>> I am just committing some new files though, so not sure what I am
>>>> doing that would be "weird".
>>> I don't see any "failing" requests. I see:
>>>
>>> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
>>> HTTP/1.1 207 Multi-Status
>>> MKACTIVITY /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
>>> HTTP/1.1 201 Created
>>> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
>>> HTTP/1.1 207 Multi-Status
>>> CHECKOUT /svn/subclipse/!svn/vcc/default HTTP/1.1
>>> HTTP/1.1 201 Created
>>> PROPPATCH /svn/subclipse/!svn/wbl/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e/5706 HTTP/1.1
>>> HTTP/1.1 207 Multi-Status
>>> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x HTTP/1.1
>>> HTTP/1.1 201 Created
>>> HEAD /svn/subclipse/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1
>>> HTTP/1.1 404 Not Found
>>> HEAD /svn/subclipse/trunk/www/update_1.10.x/content.jar HTTP/1.1
>>> HTTP/1.1 404 Not Found
>>> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x/features HTTP/1.1
>>> HTTP/1.1 201 Created
>>> DELETE /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
>>> HTTP/1.1 204 No Content
>>>
>>> Which all looks OK until the DELETE. A v1 commit done locally looks like:
>>>
>>> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 722 Length:-
>>> "MKACTIVITY /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 201 227 Length:-
>>> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 430 Length:-
>>> "CHECKOUT /obj/repo/!svn/vcc/default HTTP/1.1" 201 241 Length:-
>>> "PROPPATCH /obj/repo/!svn/wbl/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/4 HTTP/1.1" 207 517 Length:-
>>> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x HTTP/1.1" 201 263 Length:-
>>> "HEAD /obj/repo/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 404 - Length:-
>>> "HEAD /obj/repo/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 404 - Length:-
>>> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x/features HTTP/1.1" 201 272 Length:-
>>> "HEAD /obj/repo/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 404 - Length:-
>>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 201 264 Length:-
>>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 201 265 Length:-
>>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 201 315 Length:-
>>> "MERGE /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 200 2030 Length:-
>>> "DELETE /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 204 - Length:-
>>>
>>> so all the requests you show appeared to work. The client should have
>>> gone on to do HEAD, PUT, PUT, PUT but something caused it to abort the
>>> commit and send a DELETE instead.
>> Agreed, it is very weird, not even sure where to look. Not only did I
>> consistently get this problem on repeated attempts to commit, but I
>> switched from Windows to Mac, did a new checkout and got same error
>> when trying to commit again.
>>
>> I needed to do this commit, so I have since done it using 1.7 and
>> Neon. 1.7 and Serf failed with APR error code unknown, which I assume
>> was the "The server sent a truncated HTTP response body" error.
>
> Might there possibly be an HTTP/1.0 proxy at work here?
If there is, it would have to be on tigris itself. Mike Pilato could
probably answer that better. I think it is mostly a plain (although
old) Apache + SVN. The authentication and authorization stuff is
custom. I do not think there is any proxy involved.
Mike would probably have better luck than me knowing how to get any
errors logged on the server as well.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Branko Čibej <br...@wandisco.com>.
On 18.06.2013 16:34, Mark Phippard wrote:
> On Tue, Jun 18, 2013 at 10:25 AM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Mark Phippard <ma...@gmail.com> writes:
>>
>>> I also created a test project on tigris. So far, all commits are
>>> working for that project -- which I guess is good news. Maybe some
>>> odd scenario I am running into.
>>>
>>> I am just committing some new files though, so not sure what I am
>>> doing that would be "weird".
>> I don't see any "failing" requests. I see:
>>
>> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
>> HTTP/1.1 207 Multi-Status
>> MKACTIVITY /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
>> HTTP/1.1 201 Created
>> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
>> HTTP/1.1 207 Multi-Status
>> CHECKOUT /svn/subclipse/!svn/vcc/default HTTP/1.1
>> HTTP/1.1 201 Created
>> PROPPATCH /svn/subclipse/!svn/wbl/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e/5706 HTTP/1.1
>> HTTP/1.1 207 Multi-Status
>> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x HTTP/1.1
>> HTTP/1.1 201 Created
>> HEAD /svn/subclipse/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1
>> HTTP/1.1 404 Not Found
>> HEAD /svn/subclipse/trunk/www/update_1.10.x/content.jar HTTP/1.1
>> HTTP/1.1 404 Not Found
>> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x/features HTTP/1.1
>> HTTP/1.1 201 Created
>> DELETE /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
>> HTTP/1.1 204 No Content
>>
>> Which all looks OK until the DELETE. A v1 commit done locally looks like:
>>
>> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 722 Length:-
>> "MKACTIVITY /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 201 227 Length:-
>> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 430 Length:-
>> "CHECKOUT /obj/repo/!svn/vcc/default HTTP/1.1" 201 241 Length:-
>> "PROPPATCH /obj/repo/!svn/wbl/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/4 HTTP/1.1" 207 517 Length:-
>> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x HTTP/1.1" 201 263 Length:-
>> "HEAD /obj/repo/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 404 - Length:-
>> "HEAD /obj/repo/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 404 - Length:-
>> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x/features HTTP/1.1" 201 272 Length:-
>> "HEAD /obj/repo/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 404 - Length:-
>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 201 264 Length:-
>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 201 265 Length:-
>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 201 315 Length:-
>> "MERGE /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 200 2030 Length:-
>> "DELETE /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 204 - Length:-
>>
>> so all the requests you show appeared to work. The client should have
>> gone on to do HEAD, PUT, PUT, PUT but something caused it to abort the
>> commit and send a DELETE instead.
> Agreed, it is very weird, not even sure where to look. Not only did I
> consistently get this problem on repeated attempts to commit, but I
> switched from Windows to Mac, did a new checkout and got same error
> when trying to commit again.
>
> I needed to do this commit, so I have since done it using 1.7 and
> Neon. 1.7 and Serf failed with APR error code unknown, which I assume
> was the "The server sent a truncated HTTP response body" error.
Might there possibly be an HTTP/1.0 proxy at work here?
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Commit error using 1.8.0 final
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jun 18, 2013 at 4:34 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Jun 18, 2013 at 10:25 AM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Mark Phippard <ma...@gmail.com> writes:
>>
>>>
>>> I also created a test project on tigris. So far, all commits are
>>> working for that project -- which I guess is good news. Maybe some
>>> odd scenario I am running into.
>>>
>>> I am just committing some new files though, so not sure what I am
>>> doing that would be "weird".
>>
>> I don't see any "failing" requests. I see:
>>
>> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
>> HTTP/1.1 207 Multi-Status
>> MKACTIVITY /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
>> HTTP/1.1 201 Created
>> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
>> HTTP/1.1 207 Multi-Status
>> CHECKOUT /svn/subclipse/!svn/vcc/default HTTP/1.1
>> HTTP/1.1 201 Created
>> PROPPATCH /svn/subclipse/!svn/wbl/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e/5706 HTTP/1.1
>> HTTP/1.1 207 Multi-Status
>> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x HTTP/1.1
>> HTTP/1.1 201 Created
>> HEAD /svn/subclipse/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1
>> HTTP/1.1 404 Not Found
>> HEAD /svn/subclipse/trunk/www/update_1.10.x/content.jar HTTP/1.1
>> HTTP/1.1 404 Not Found
>> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x/features HTTP/1.1
>> HTTP/1.1 201 Created
>> DELETE /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
>> HTTP/1.1 204 No Content
>>
>> Which all looks OK until the DELETE. A v1 commit done locally looks like:
>>
>> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 722 Length:-
>> "MKACTIVITY /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 201 227 Length:-
>> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 430 Length:-
>> "CHECKOUT /obj/repo/!svn/vcc/default HTTP/1.1" 201 241 Length:-
>> "PROPPATCH /obj/repo/!svn/wbl/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/4 HTTP/1.1" 207 517 Length:-
>> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x HTTP/1.1" 201 263 Length:-
>> "HEAD /obj/repo/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 404 - Length:-
>> "HEAD /obj/repo/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 404 - Length:-
>> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x/features HTTP/1.1" 201 272 Length:-
>> "HEAD /obj/repo/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 404 - Length:-
>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 201 264 Length:-
>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 201 265 Length:-
>> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 201 315 Length:-
>> "MERGE /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 200 2030 Length:-
>> "DELETE /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 204 - Length:-
>>
>> so all the requests you show appeared to work. The client should have
>> gone on to do HEAD, PUT, PUT, PUT but something caused it to abort the
>> commit and send a DELETE instead.
>
> Agreed, it is very weird, not even sure where to look. Not only did I
> consistently get this problem on repeated attempts to commit, but I
> switched from Windows to Mac, did a new checkout and got same error
> when trying to commit again.
>
> I needed to do this commit, so I have since done it using 1.7 and
> Neon. 1.7 and Serf failed with APR error code unknown, which I assume
> was the "The server sent a truncated HTTP response body" error.
>
Is there something in the server-side error logs?
--
Johan
Re: Commit error using 1.8.0 final
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jun 18, 2013 at 10:25 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Mark Phippard <ma...@gmail.com> writes:
>
>>
>> I also created a test project on tigris. So far, all commits are
>> working for that project -- which I guess is good news. Maybe some
>> odd scenario I am running into.
>>
>> I am just committing some new files though, so not sure what I am
>> doing that would be "weird".
>
> I don't see any "failing" requests. I see:
>
> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
> HTTP/1.1 207 Multi-Status
> MKACTIVITY /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
> HTTP/1.1 201 Created
> PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
> HTTP/1.1 207 Multi-Status
> CHECKOUT /svn/subclipse/!svn/vcc/default HTTP/1.1
> HTTP/1.1 201 Created
> PROPPATCH /svn/subclipse/!svn/wbl/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e/5706 HTTP/1.1
> HTTP/1.1 207 Multi-Status
> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x HTTP/1.1
> HTTP/1.1 201 Created
> HEAD /svn/subclipse/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1
> HTTP/1.1 404 Not Found
> HEAD /svn/subclipse/trunk/www/update_1.10.x/content.jar HTTP/1.1
> HTTP/1.1 404 Not Found
> CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x/features HTTP/1.1
> HTTP/1.1 201 Created
> DELETE /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
> HTTP/1.1 204 No Content
>
> Which all looks OK until the DELETE. A v1 commit done locally looks like:
>
> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 722 Length:-
> "MKACTIVITY /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 201 227 Length:-
> "PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 430 Length:-
> "CHECKOUT /obj/repo/!svn/vcc/default HTTP/1.1" 201 241 Length:-
> "PROPPATCH /obj/repo/!svn/wbl/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/4 HTTP/1.1" 207 517 Length:-
> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x HTTP/1.1" 201 263 Length:-
> "HEAD /obj/repo/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 404 - Length:-
> "HEAD /obj/repo/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 404 - Length:-
> "CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x/features HTTP/1.1" 201 272 Length:-
> "HEAD /obj/repo/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 404 - Length:-
> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 201 264 Length:-
> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 201 265 Length:-
> "PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 201 315 Length:-
> "MERGE /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 200 2030 Length:-
> "DELETE /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 204 - Length:-
>
> so all the requests you show appeared to work. The client should have
> gone on to do HEAD, PUT, PUT, PUT but something caused it to abort the
> commit and send a DELETE instead.
Agreed, it is very weird, not even sure where to look. Not only did I
consistently get this problem on repeated attempts to commit, but I
switched from Windows to Mac, did a new checkout and got same error
when trying to commit again.
I needed to do this commit, so I have since done it using 1.7 and
Neon. 1.7 and Serf failed with APR error code unknown, which I assume
was the "The server sent a truncated HTTP response body" error.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
>
> I also created a test project on tigris. So far, all commits are
> working for that project -- which I guess is good news. Maybe some
> odd scenario I am running into.
>
> I am just committing some new files though, so not sure what I am
> doing that would be "weird".
I don't see any "failing" requests. I see:
PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
HTTP/1.1 207 Multi-Status
MKACTIVITY /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
HTTP/1.1 201 Created
PROPFIND /svn/subclipse/trunk/www/update_1.10.x HTTP/1.1
HTTP/1.1 207 Multi-Status
CHECKOUT /svn/subclipse/!svn/vcc/default HTTP/1.1
HTTP/1.1 201 Created
PROPPATCH /svn/subclipse/!svn/wbl/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e/5706 HTTP/1.1
HTTP/1.1 207 Multi-Status
CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x HTTP/1.1
HTTP/1.1 201 Created
HEAD /svn/subclipse/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1
HTTP/1.1 404 Not Found
HEAD /svn/subclipse/trunk/www/update_1.10.x/content.jar HTTP/1.1
HTTP/1.1 404 Not Found
CHECKOUT /svn/subclipse/!svn/ver/5706/trunk/www/update_1.10.x/features HTTP/1.1
HTTP/1.1 201 Created
DELETE /svn/subclipse/!svn/act/5ea43b8a-0d4e-4ef0-8c62-5be2e0291f8e HTTP/1.1
HTTP/1.1 204 No Content
Which all looks OK until the DELETE. A v1 commit done locally looks like:
"PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 722 Length:-
"MKACTIVITY /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 201 227 Length:-
"PROPFIND /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 207 430 Length:-
"CHECKOUT /obj/repo/!svn/vcc/default HTTP/1.1" 201 241 Length:-
"PROPPATCH /obj/repo/!svn/wbl/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/4 HTTP/1.1" 207 517 Length:-
"CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x HTTP/1.1" 201 263 Length:-
"HEAD /obj/repo/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 404 - Length:-
"HEAD /obj/repo/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 404 - Length:-
"CHECKOUT /obj/repo/!svn/ver/4/trunk/www/update_1.10.x/features HTTP/1.1" 201 272 Length:-
"HEAD /obj/repo/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 404 - Length:-
"PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/contents.jar HTTP/1.1" 201 264 Length:-
"PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/artifacts.jar HTTP/1.1" 201 265 Length:-
"PUT /obj/repo/!svn/wrk/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b/trunk/www/update_1.10.x/features/org.tigris.subversion.clientadapter.feature_1.10.0.jar HTTP/1.1" 201 315 Length:-
"MERGE /obj/repo/trunk/www/update_1.10.x HTTP/1.1" 200 2030 Length:-
"DELETE /obj/repo/!svn/act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1" 204 - Length:-
so all the requests you show appeared to work. The client should have
gone on to do HEAD, PUT, PUT, PUT but something caused it to abort the
commit and send a DELETE instead.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Re: Commit error using 1.8.0 final
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jun 17, 2013 at 4:00 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
> On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
>> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
>> change for Subclipse to tigris.org and it is failing. The error
>> message is not that helpful. Any ideas how to get better error
>> information?
>
> There might be a higher level option, but in serf you can enable lots
> of debug logging, at compile time in serf_private.h.
> SSL_VERBOSE gives huge amount of log lines but is probably what you
> need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
I turned on everything and ran command again. Attaching the output.
I also created a test project on tigris. So far, all commits are
working for that project -- which I guess is good news. Maybe some
odd scenario I am running into.
I am just committing some new files though, so not sure what I am
doing that would be "weird".
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Commit error using 1.8.0 final
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Mon, Jun 17, 2013 at 9:22 PM, Mark Phippard <ma...@gmail.com> wrote:
> I updated my Windows laptop to 1.8.0 final. I am trying to commit a
> change for Subclipse to tigris.org and it is failing. The error
> message is not that helpful. Any ideas how to get better error
> information?
There might be a higher level option, but in serf you can enable lots
of debug logging, at compile time in serf_private.h.
SSL_VERBOSE gives huge amount of log lines but is probably what you
need here, other interesting flags are SOCK_VERBOSE and CONN_VERBOSE.
Lieven
>>svn ci -m "Post 1.10.0 release" trunk
> Sending trunk\subclipse\org.tigris.subversion.clientadapter.javahl.feature\feature.xml
> Sending trunk\subclipse\org.tigris.subversion.clientadapter.javahl.win64\META-INF\MANIFEST.MF
> Adding (bin) trunk\www\update_1.10.x\artifacts.jar
> Adding (bin) trunk\www\update_1.10.x\content.jar
> Adding (bin) trunk\www\update_1.10.x\features\org.tigris.subversion.clientadapter.feature_1.10.0.jar
> svn: E120106: Commit failed (details follow):
> svn: E120106: Error running context: The server sent a truncated HTTP
> response body.
>
>> svn --version --verbose
>
> svn, version 1.8.0 (r1490375)
> compiled Jun 16 2013, 22:17:12 on x86-microsoft-windows5.1.2600
>
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network protocol.
> - with Cyrus SASL authentication
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
> - handles 'http' scheme
> - handles 'https' scheme
>
> System information:
>
> * running on x86/x86_64-microsoft-windows6.1.7601
> - Windows 7 Professional, Service Pack 1, build 7601 [6.1 Client
> Multiprocessor Free]
> * linked dependencies:
> - APR 1.4.6 (compiled with 1.4.6)
> - APR-Util 1.5.1 (compiled with 1.5.1)
> - SQLite 3.7.16.1 (static)
> * loaded shared libraries:
> - C:\Program Files (x86)\CollabNet\Subversion Client\svn.exe (1.8.0.48583)
> - C:\Windows\SysWOW64\ntdll.dll (6.1.7601.17725)
> - C:\Windows\syswow64\kernel32.dll (6.1.7601.18015)
> - C:\Windows\syswow64\KERNELBASE.dll (6.1.7601.18015)
> - C:\Windows\SysWOW64\SYSFER.DLL (12.1.2015.2015)
> - C:\Program Files (x86)\CollabNet\Subversion Client\libapr-1.dll (1.4.6)
> - C:\Windows\syswow64\WS2_32.dll (6.1.7601.17514)
> - C:\Windows\syswow64\msvcrt.dll (7.0.7601.17744)
> - C:\Windows\syswow64\RPCRT4.dll (6.1.7601.17514)
> - C:\Windows\syswow64\SspiCli.dll (6.1.7601.17940)
> - C:\Windows\syswow64\CRYPTBASE.dll (6.1.7600.16385)
> - C:\Windows\SysWOW64\sechost.dll (6.1.7600.16385)
> - C:\Windows\syswow64\NSI.dll (6.1.7600.16385)
> - C:\Windows\system32\MSWSOCK.dll (6.1.7601.17514)
> - C:\Windows\syswow64\user32.dll (6.1.7601.17514)
> - C:\Windows\syswow64\GDI32.dll (6.1.7601.17514)
> - C:\Windows\syswow64\LPK.dll (6.1.7600.16385)
> - C:\Windows\syswow64\USP10.dll (1.626.7601.18009)
> - C:\Windows\syswow64\ADVAPI32.dll (6.1.7601.17514)
> - C:\Windows\syswow64\SHELL32.dll (6.1.7601.18103)
> - C:\Windows\syswow64\SHLWAPI.dll (6.1.7601.17514)
> - C:\Program Files (x86)\CollabNet\Subversion Client\MSVCR100.dll
> (10.0.40219.325)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libsvn_client-1.dll (1.8.0.48583)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libsvn_delta-1.dll (1.8.0.48583)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libaprutil-1.dll (1.5.1)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libapriconv-1.dll (1.2.1)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libsvn_subr-1.dll (1.8.0.48583)
> - C:\Windows\system32\SHFOLDER.dll (6.1.7600.16385)
> - C:\Windows\syswow64\ole32.dll (6.1.7601.17514)
> - C:\Windows\syswow64\CRYPT32.dll (6.1.7601.18151)
> - C:\Windows\syswow64\MSASN1.dll (6.1.7601.17514)
> - C:\Windows\system32\VERSION.dll (6.1.7600.16385)
> - C:\Windows\syswow64\PSAPI.DLL (6.1.7600.16385)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libsvn_diff-1.dll (1.8.0.48583)
> - C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_ra-1.dll
> (1.8.0.48583)
> - C:\Program Files (x86)\CollabNet\Subversion Client\LIBEAY32.dll (1.0.1.5)
> - C:\Program Files (x86)\CollabNet\Subversion Client\SSLEAY32.dll (1.0.1.5)
> - C:\Windows\system32\Secur32.dll (6.1.7601.17940)
> - C:\Program Files (x86)\CollabNet\Subversion Client\libsasl.dll (2.1.23)
> - C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_fs-1.dll
> (1.8.0.48583)
> - C:\Program Files (x86)\CollabNet\Subversion
> Client\libsvn_repos-1.dll (1.8.0.48583)
> - C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_wc-1.dll
> (1.8.0.48583)
> - C:\Windows\system32\IMM32.DLL (6.1.7601.17514)
> - C:\Windows\syswow64\MSCTF.dll (6.1.7600.16385)
> - C:\Windows\system32\profapi.dll (6.1.7600.16385)
>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/