Crash Log

[。。]

fyi.

svn-crash-log20161110074401.dmp
Description: Binary data

Process info:
Cmd line: "D:\Program Files\SlikSvn\bin\svn.exe" update
Working Dir: D:\workspace\0.94.0-ali-1.0
Version:  1.8.9-SlikSvn-1.8.9-X64 (SlikSvn/1.8.9) X64, compiled May  8 2014, 
20:00:31
Platform: Windows OS version 6.1 build 7601 Service Pack 1

Exception: ACCESS_VIOLATION

Registers:
Rax=02b131b8 Rcx=0015ece0 Rdx=612d7473616c3a79 
Rbx=0015ece0
Rsp=0015ec40 Rbp=02b15240 Rsi=00c8 
Rdi=02b0fca0
R8= 0015ecd8 R9= 0015ecd0 R10= 0005 
R11=
R12=02f55038 R13=02b13200 R14= 
R15=02aef0a0
cs=0033  ss=002b  ds=002b  es=0053  fs=002b  gs=002b  ss=0094

Stacktrace:
#1  0x7feeacd4c13 in svn_wc_add_repos_file4()
#2  0x7feecbbd3a4 in svn_ra_svn_init()
#3  0x7feecbb74d9 in svn_ra_svn_init()
#4  0x7feecbb759c in svn_ra_svn_init()
#5  0x7feecb80479 in (unknown function)
#6  0x7feecb80817 in (unknown function)
#7  0x7feecb80a0a in (unknown function)
#8  0x7feecb7edaa in (unknown function)
#9  0x7feecb7ef05 in (unknown function)
#10  0x7feecbbfa4f in svn_ra_svn_init()
#11  0x7feeacac746 in svn_wc_crawl_revisions5()
#12  0x7feeedda914 in svn_client_url_from_path2()
#13  0x7feeeddad4c in svn_client_url_from_path2()
#14  0x7feeeddaf92 in svn_client_update4()
#15  0x13f8236f4 in (unknown function)
#16  0x13f825870 in (unknown function)
#17  0x13f825d10 in (unknown function)
#18  0x13f8211f2 in (unknown function)
#19  0x76e359bd in BaseThreadInitThunk()
#20  0x7706a2e1 in RtlUserThreadStart()


Loaded modules:
0x00013f82  D:\Program Files\SlikSvn\bin\svn.exe (1.8.9.18516, 294912 
bytes)
0x7704  C:\Windows\System32\ntdll.dll (6.1.7601.23418, 1744896 
bytes)
0x76e2  C:\Windows\System32\kernel32.dll (6.1.7601.23418, 1175552 
bytes)
0x07fefd02  C:\Windows\System32\KERNELBASE.dll (6.1.7601.23418, 434176 
bytes)
0x66f3  D:\Program Files\SlikSvn\bin\SlikSvn-libintl.dll (0.0.0.0, 
77824 bytes)
0x07fefe5b  C:\Windows\System32\advapi32.dll (6.1.7601.23418, 897024 
bytes)
0x07fefd14  C:\Windows\System32\msvcrt.dll (7.0.7601.17744, 651264 
bytes)
0x07fefed8  C:\Windows\System32\sechost.dll (6.1.7601.18869, 126976 
bytes)
0x07fefe71  C:\Windows\System32\rpcrt4.dll (6.1.7601.23497, 1232896 
bytes)
0x7944  C:\Windows\System32\msvcr100.dll (10.0.40219.325, 860160 
bytes)
0x07fef239  D:\Program Files\SlikSvn\bin\SlikSvn-libapr-1.dll (1.5.1.0, 
221184 bytes)
0x07fefd60  C:\Windows\System32\shell32.dll (6.1.7601.23418, 14204928 
bytes)
0x07fefe69  C:\Windows\System32\shlwapi.dll (6.1.7601.17514, 462848 
bytes)
0x07fefe39  C:\Windows\System32\gdi32.dll (6.1.7601.23457, 421888 bytes)
0x76f4  C:\Windows\System32\user32.dll (6.1.7601.19061, 1024000 
bytes)
0x07feff0c  C:\Windows\System32\lpk.dll (6.1.7601.23453, 57344 bytes)
0x07fefead  C:\Windows\System32\usp10.dll (1.626.7601.19054, 827392 
bytes)
0x07fefeda  C:\Windows\System32\ws2_32.dll (6.1.7601.23451, 315392 
bytes)
0x07fefd1e  C:\Windows\System32\nsi.dll (6.1.7600.16385, 32768 bytes)
0x07fefc50  C:\Windows\System32\mswsock.dll (6.1.7601.23451, 348160 
bytes)
0x07feeedd  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_client-1.dll 
(1.8.9.18516, 434176 bytes)
0x07feef46  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_delta-1.dll 
(1.8.9.18516, 155648 bytes)
0x07feecf0  D:\Program Files\SlikSvn\bin\SlikSvn-libaprutil-1.dll 
(1.5.3.0, 294912 bytes)
0x07feead3  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_subr-1.dll 
(1.8.9.18516, 1294336 bytes)
0x07fef238  C:\Windows\System32\shfolder.dll (6.1.7600.16385, 28672 
bytes)
0x07fefe84  C:\Windows\System32\ole32.dll (6.1.7601.23392, 2109440 
bytes)
0x07fefce9  C:\Windows\System32\crypt32.dll (6.1.7601.18839, 1495040 
bytes)
0x07fefcd9  C:\Windows\System32\msasn1.dll (6.1.7601.17514, 61440 bytes)
0x07fefbe0  C:\Windows\System32\version.dll (6.1.7600.16385, 49152 
bytes)
0x07fef0d8  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_diff-1.dll 
(1.8.9.18516, 110592 bytes)
0x07feecb6  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_ra-1.dll 
(1.8.9.18516, 614400 bytes)
0x07feeecf  D:\Program Files\SlikSvn\bin\SlikSvn-libsasl21.dll 
(2.1.25.0, 204800 bytes)
0x07feec2d  D:\Program Files\SlikSvn\bin\SlikSvn-SSLEAY32.dll (1.0.1.7, 
360448 bytes)
0x07feea74  D:\Program Files\SlikSvn\bin\SlikSvn-LIBEAY32.dll (1.0.1.7, 
1597440 bytes)
0x07feec25  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_fs-1.dll 
(1.8.9.18516, 475136 bytes)
0x6650  D:\Program Files\SlikSvn\bin\SlikSvn-DB44-20-x64.dll 
(4.0.4.20, 794624 bytes)
0x07feec21  D:\Program Files\SlikSvn\bin\SlikSvn-libsvn_repos-1.dll 
(1.8.9.18516, 229376 bytes)
0x07fefc99  C:\Windows\System32\secur32.

Re: Crash Log

[Pavel Lyalyakin]

Hello,

On Thu, Nov 10, 2016 at 10:52 AM, 。。  wrote:
>
> fyi.

Upgrade your Subversion client. You use an outdated SVN 1.8.9, but the most
recent 1.8.x version is 1.8.16. You could also consider upgrading to the
latest 1.9.x version.

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: Feature request: Restoring pristines

[Stefan Hett]

On 11/10/2016 8:08 AM, Cooke, Mark wrote:

-Original Message-
From: Stefan [mailto:luke1...@posteo.de]
Sent: 09 November 2016 21:43
To: users@subversion.apache.org
Subject: Re: Feature request: Restoring pristines

On 11/9/2016 21:22, Branko Čibej wrote:

On 08.11.2016 21:51, Stefan wrote:

I didn't test this, but

This is how all down-voted stackoverflow answers start. :)

-- Brane


OK, I see. Tested and it doesn't work. ;-)

Certainly sounds like a reasonable request for an improvement to have at
least svn co auto correct the case of missing pristine files, as far as
I'm concerned.

Regards,
Stefan

Would this not fit better as part of `update` rather than `checkout` over an 
existing working copy?

~ mark c

IMO it should be part of both, since both operations (aka: svn update as 
well as svn checkout) will error out, if a pristine would be required 
but missing (and this is some error, the operation could easily resolve 
without user interaction).


Why I pointed out svn co: IMO in this case it would be reasonable for 
the co command to check all required pristine files to verify they exist 
and are valid. That's certainly something you wouldn't want a simple svn 
up to do.


--
Regards,
Stefan Hett

Re: svnserve not reading hooks-env?

[Steven Simpson]

Hi Stefan,

On 10/11/16 00:07, Stefan wrote:

On 11/10/2016 00:45, Steven Simpson wrote:

PROBLEM: When attempting to commit via SSH, I get errors from my
scripts indicating that they haven't found the REPOWEBMAN_CONFIG
setting, so they fail, and the commit fails.  HTTPS-invoked hooks work
fine.

So if I get you right you are saying that someone connecting to the
server via https://[URL] causes the hook to run as expected while
someone using svn+ssh://[URL] triggers the hook but that fails due to
REPOWEBMAN_CONFIG not being set?


Correct.


If I get you right, I can't follow you why you think REPOWEBMAN_CONFIG
would be set in the svn+ssh-case (or maybe I'm lacking some knowledge
here?).
You stated that you specified REPOWEBMAN_CONFIG in
/etc/forge/svn-hooks-env.ini which is set in the Apache config (aka:
applies when someone uses https://[URL]).

You also state that you start svnserve with the config file being set to
/etc/forge/svnserve.ini. But where would you expect the connection to
the REPOWEBMAN_CONFIG-environment variable here?


if you create a fresh repo with svnadmin create, a default 
conf/svnserve.conf is created containing:


[general]
(...snip...)
### The authz-db option controls the location of the authorization
### rules for path-based access control.  Unless you specify a path
### starting with a /, the file's location is relative to the
### directory containing this file.  The specified path may be a
### repository relative URL (^/) or an absolute file:// URL to a text
### file in a Subversion repository.  If you don't specify an authz-db,
### no path-based access control is done.
### Uncomment the line below to use the default authorization file.
# authz-db = authz
(...snip...)
### The hooks-env options specifies a path to the hook script environment
### configuration file. This option overrides the per-repository default
### and can be used to configure the hook script environment for multiple
### repositories in a single file, if an absolute path is specified.
### Unless you specify an absolute path, the file's location is relative
### to the directory containing this file.
# hooks-env = hooks-env

These are the two options I've set in /etc/forge/svnserve.ini.  The 
authz-db option is effective, as I can make it point at a non-existent 
file to force an error, but the hooks-env option seems to have no effect.


Given that, this trace from inside a repo should make sense, right?:

$ ls -F conf/
authz  hooks-env@  passwd  svnserve.conf@  svnserve.conf-orig
$ readlink -f conf/hooks-env conf/svnserve.conf
/etc/forge/svn-hooks-env.ini
/etc/forge/svnserve.ini
$ cat /etc/forge/svnserve.ini
[general]
authz-db=/var/forge/service/svn-authz.conf
hooks-env=/etc/forge/svn-hooks-env.ini
$ cat /etc/forge/svn-hooks-env.ini
[default]
LANG=en_GB.UTF-8
PATH=/usr/bin:/bin
REPOWEBMAN_CONFIG=/etc/forge/repowebman.ini

Even if svnserve is ignoring the hooks-env option, conf/hooks-env 
symlinks to the same file (and that is effective for  access).



Am I missing something
or is this actually the cause of your problem?


I'm starting to think that hooks-env with svnserve is a documented 
unfeature.  ;-)  I don't see it in the 1.7 docs, but it is in 1.8:




I think I will have to do it the old-fashioned way.

Cheers!

Re: Feature request: Restoring pristines

[Daniel Shahaf]

Stefan Hett wrote on Thu, Nov 10, 2016 at 11:52:43 +0100:
> On 11/10/2016 8:08 AM, Cooke, Mark wrote:
> >>-Original Message-
> >>From: Stefan [mailto:luke1...@posteo.de]
> >>Sent: 09 November 2016 21:43
> >>To: users@subversion.apache.org
> >>Subject: Re: Feature request: Restoring pristines
> >>
> >>On 11/9/2016 21:22, Branko Čibej wrote:
> >>>On 08.11.2016 21:51, Stefan wrote:
> I didn't test this, but
> >>>This is how all down-voted stackoverflow answers start. :)
> >>>
> >>>-- Brane
> >>>
> >>OK, I see. Tested and it doesn't work. ;-)
> >>
> >>Certainly sounds like a reasonable request for an improvement to have at
> >>least svn co auto correct the case of missing pristine files, as far as
> >>I'm concerned.
> >>
> >>Regards,
> >>Stefan
> >Would this not fit better as part of `update` rather than `checkout` over an 
> >existing working copy?
> >
> >~ mark c
> >
> IMO it should be part of both, since both operations (aka: svn update as
> well as svn checkout) will error out, if a pristine would be required but
> missing (and this is some error, the operation could easily resolve without
> user interaction).
> 

I thought of 'cleanup' as the appropriate place, since fixing violated
invariants should be opt-in;

However, let's not bikeshed about the UI.  My concern about this change
is that by the time a pristine is absent, one invariant is no longer
holding so there may be additional problems.  I.e., there's no guarantee
that after running «svn cleanup --reinvariant=missing-pristines» the wc
will be in a valid state.

That said, the feature might be useful in certain cases and ought to be
pretty easy to implement, so perhaps someone will write it?  It might
even make sense to write it as an external script, at least at first, to
(a) shake out any bugs, (b) allow users of 1.9 and older to use it.

The external script should be quite short; it just needs to check
SVN_WC__VERSION, then to run `svn info` and `svn cat`.  (That's assuming
the on-disk file is missing but the sqlite entry (in the PRISTINES
table) is still present.)

Cheers,

Daniel

Re: Feature request: Restoring pristines

[Branko Čibej]

On 10.11.2016 17:19, Daniel Shahaf wrote:
> Stefan Hett wrote on Thu, Nov 10, 2016 at 11:52:43 +0100:
>> On 11/10/2016 8:08 AM, Cooke, Mark wrote:
 -Original Message-
 From: Stefan [mailto:luke1...@posteo.de]
 Sent: 09 November 2016 21:43
 To: users@subversion.apache.org
 Subject: Re: Feature request: Restoring pristines

 On 11/9/2016 21:22, Branko Čibej wrote:
> On 08.11.2016 21:51, Stefan wrote:
>> I didn't test this, but
> This is how all down-voted stackoverflow answers start. :)
>
> -- Brane
>
 OK, I see. Tested and it doesn't work. ;-)

 Certainly sounds like a reasonable request for an improvement to have at
 least svn co auto correct the case of missing pristine files, as far as
 I'm concerned.

 Regards,
 Stefan
>>> Would this not fit better as part of `update` rather than `checkout` over 
>>> an existing working copy?
>>>
>>> ~ mark c
>>>
>> IMO it should be part of both, since both operations (aka: svn update as
>> well as svn checkout) will error out, if a pristine would be required but
>> missing (and this is some error, the operation could easily resolve without
>> user interaction).
>>
> I thought of 'cleanup' as the appropriate place, since fixing violated
> invariants should be opt-in;

An option that makes 'svn cleanup' connect to the repository? Cleanup
has always been a local-only command.

-- Brane

Re: svnserve not reading hooks-env?

[Stefan Sperling]

On Thu, Nov 10, 2016 at 02:56:26PM +, Steven Simpson wrote:
> I'm starting to think that hooks-env with svnserve is a documented
> unfeature.  ;-)  I don't see it in the 1.7 docs, but it is in 1.8:
> 
> 
> 
> I think I will have to do it the old-fashioned way.
> 
> Cheers!
> 

This looks like a bug where svnserve forgets about applying
a hook environment config after opening the repository.
So hooks always run in an empty environment with svnserve.

Ooops. I'm amazed it took so long for someone to notice :-)

This should fix it:

Index: subversion/svnserve/serve.c
===
--- subversion/svnserve/serve.c (revision 1768932)
+++ subversion/svnserve/serve.c (working copy)
@@ -3867,6 +3867,7 @@ find_repos(const char *url,
   if (hooks_env)
 hooks_env = svn_dirent_internal_style(hooks_env, scratch_pool);
 
+  SVN_ERR(svn_repos_hooks_setenv(repository->repos, hooks_env, scratch_pool));
   repository->hooks_env = apr_pstrdup(result_pool, hooks_env);
 
   return SVN_NO_ERROR;

Re: svnserve not reading hooks-env?

[Steven Simpson]

On 10/11/16 16:40, Stefan Sperling wrote:

This looks like a bug where svnserve forgets about applying
a hook environment config after opening the repository.
So hooks always run in an empty environment with svnserve.

Ooops. I'm amazed it took so long for someone to notice :-)

This should fix it:


Cool - thanks!

Re: svnserve not reading hooks-env?

[Stefan Sperling]

On Thu, Nov 10, 2016 at 08:12:11PM +, Steven Simpson wrote:
> On 10/11/16 16:40, Stefan Sperling wrote:
> > This looks like a bug where svnserve forgets about applying
> > a hook environment config after opening the repository.
> > So hooks always run in an empty environment with svnserve.
> > 
> > Ooops. I'm amazed it took so long for someone to notice :-)
> > 
> > This should fix it:
> 
> Cool - thanks!

I have reproduced the problem and have confirmed that the patch fixes it.
And I have nominated the fix for 1.9.5: http://svn.apache.org/r1769156