[PATCH] issue #3242: fix another occurence

Hi, the fixes for issue 3242 ("Subversion demands unnecessary access to parent directories of operations") currently in trunk do not address scenario gicen below. [[[ Fix another scenario related to issue #3242: - user has no access in repo root, only in /project - someone else renames some file

Re: [PATCH] issue #3242: fix another occurence

On Mon, Apr 12, 2010 at 6:21 PM, C. Michael Pilato wrote: > Melikes.  Committed with minor tweaks in r933299. > > The minor tweaks were a comment change in the ff_baton structure, some > indentation tweaks, and then the use of the operation/callback pool instead > of the more permanent baton pool

Thinko in libsvn_client/merge.c?

Hi, while looking at calls of svn_client__open_ra_session_internal (to check for unnecessarily opening a session in the repository root) I stumbled about the following (first few lines of function merge_reintegrate_locked in libsvn_client/merge.c): static svn_error_t * merge_reintegrate_locked(co

Re: Thinko in libsvn_client/merge.c?

On Tue, Apr 13, 2010 at 4:37 PM, C. Michael Pilato wrote: > ... Have you > tried the suggested fix to see how it affects our test suite runs?  Would > you be willing/able to generate, test, and transmit a patch to that affect? Will do, it will take a day or so. Cheers, Roderich

[PATCH] Re: Thinko in libsvn_client/merge.c?

On Thu, Apr 15, 2010 at 2:25 PM, C. Michael Pilato wrote: > Roderich Schupp wrote: >> On Tue, Apr 13, 2010 at 4:37 PM, C. Michael Pilato >> wrote: > Cool.  I'll watch for your followup posts, and be glad to try to answer any > questions you might have about the code.

[PATCH] Excessive memory use with "SVNPathAuthz short_circuit"

Hi, recently our production Subversion servers blew up to allocate ~20 GB of memory per Apache worker process (normal usage would be ~2 GB at most). The culprit turned out to repeated requests like this: svn log --stop-on-copy --xml --revision 10574:74748 https://server/repository_root (Don

Re: [PATCH] Excessive memory use with "SVNPathAuthz short_circuit"

On Tue, Sep 18, 2012 at 9:11 PM, Philip Martin wrote: > ... > The problem is that when > dav_svn__allow_read calls allow_read_bypass (which is subreq_bypass) > this pool can't be passed and the request pool is used. > > I'm not sure how best to solve this. Your patch certainly is one > solution.

Re: [PATCH] Excessive memory use with "SVNPathAuthz short_circuit"

On Wed, Sep 19, 2012 at 10:24 AM, Roderich Schupp wrote: > Change the definition of authz_svn__subreq_bypass_func_t (adding a > pool parameter) > and its one and only implementation subreq_bypass? Patch attached, grabs the same amount of memory as my first version. > Since this defi

Re: [PATCH] Excessive memory use with "SVNPathAuthz short_circuit"

On Thu, Sep 20, 2012 at 12:19 PM, Ivan Zhakov wrote: > Commited in r1387943. Thanks! And with this patch, memory consumption for my test case for "SVNPathAuthz short_circuit" is now even lower than for "SVNPathAuthz on". Cheers, Roderich

Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

On Wed, Oct 24, 2012 at 12:08 AM, Thomas Åkesson wrote: > Are you saying that SVN 1.7 always allows browsing the root but it is empty > when the user lacks authz? Yes - for a "standalone" repository (i.e. one specified with SVNPath, _not_ with SVNParentPath) Cheers, Roderich

Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

On Wed, Oct 24, 2012 at 6:09 AM, Daniel Shahaf wrote: > Daniel Shahaf wrote on Wed, Oct 24, 2012 at 06:07:45 +0200: >> I can't reproduce this. 'curl -s https://svn.apache.org/repos/private/' > Since I didn't pass -u, in both cases I was browsing as an anonymous user. >> That server runs 1.7.0. S

Re: [PATCH] Small fixes to the Perl bindings

On Tue, Feb 12, 2013 at 6:06 PM, Ben Reser wrote: > FYI you may want to apply the changes in r1445267 to your local copy. > I found a bug in the conversion of the svn_opt_revision_t typemap to > use a function. > Ouch. Your diagnosis is correct, though I can't reproduce your symptoms :) The pre

Re: [PATCH] Small fixes to the Perl bindings

On Wed, Feb 13, 2013 at 5:28 PM, Ben Reser wrote: > ... Retrieving values out of a > svn_opt_revision_t object would have exercised the issue since you're > calling the generated accessor function > Err, no. The accessor functions don't go through the typemap, only the wrappers for "real" functi

Re: [PATCH] Small fixes to the Perl bindings

On Fri, Feb 15, 2013 at 8:41 PM, Ben Reser wrote: > I flipped through the changelog for SWIG and I didn't see anything > that explains this difference in behavior. > I used swig 2.0.9, but the change happened from 2.0.4 to 2.0.5. A quick "git bisect" puts the blame on https://github.com/swig/sw

Re: 0.2 draft of dumpfile documentation

On Thu, Dec 15, 2011 at 11:14 AM, Daniel Shahaf wrote: > Is this by design or by accident of implementation? I think the latter. The code is in subversion/libsvn_repos/dump.c starting around line 318. Some people might call that an ugly hack :) > svn_delta_editor_t has no concept of 'replace' an

Re: 0.2 draft of dumpfile documentation

On Thu, Dec 15, 2011 at 11:44 AM, Daniel Shahaf wrote: > Roderich Schupp wrote on Thu, Dec 15, 2011 at 11:32:40 +0100: >> I think the latter. The code is in subversion/libsvn_repos/dump.c starting >> around line 318. Some people might call that an ugly hack :) > > Yeah.  I

Re: svn ingores DESTDIR, was: link error with 1.7.3

On Mon, Mar 12, 2012 at 16:12, Stefan Sperling wrote: > It might be some dependency that rupert needs for this build and which > is either located in /usr/lib64 or needs a library installed there. Probably. But that is no reason to inject -L/usr/lib64 into the linker flags - pkg-config files shou

[PATCH] Expand Perl bindings a bit

Hi, the following patches enable the use of svn_client_log[34] (and probably similar functions) from Perl. (Actually I wanted to use svn_client_log5, but that needs more work for the revision_ranges parameter). Cheers, Roderich thunk_log_entry_receiver.patch: [[[ Add Perl thunk for the svn_log_

Re: [PATCH] Expand Perl bindings a bit

On Tue, Apr 16, 2013 at 11:35 AM, Philip Martin wrote: > Can you provide a bit more explanation for the removal of > revprop_table and changelists from MAY_BE_NULL Can't pretend that I understand Swig very well either... But what sense does it make to apply the mapping for some const char* to a a

Re: [PATCH] Expand Perl bindings a bit

On Tue, Apr 16, 2013 at 6:15 PM, Philip Martin wrote: > I've applied your patch in r1468487, thanks! Thanks. Here's a small extension: add an in typemap for apr_hash_t *PROPHASH. This will enable the use of many non-deprecated methods in libsvn_client, e.g. all with parameters of apr_hash_t *revp

Re: [PATCH] Expand Perl bindings a bit

On Thu, Apr 18, 2013 at 8:53 AM, Roderich Schupp wrote: > Here's a small extension Forgot to add the patch... perl-bindings.patch Description: Binary data

Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

On Sun, Jul 7, 2013 at 3:14 PM, Daniel Shahaf wrote: > > - POD: Use modern sub parameter conventions in POD (no more > "shift"ing). > > These all non-functional changes. We don't normally backport such changes > There's a difference between Subversion proper and the (Perl, Python, Ruby) bindi

Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

On Sun, Jul 7, 2013 at 5:11 PM, Daniel Shahaf wrote: > Nothing is useful without proper documentation, but devil's advocate > says the bindings can be quite usable if you document only the delta > between SVN::Client->info42 and svn_client_info42(). > First of all, you have to tell people that t

Re: Perl bindings docstrings Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

On Sun, Jul 7, 2013 at 7:33 PM, Daniel Shahaf wrote: > Or perhaps we should look into a way to generate > the Perl bindings' docstrings from the C API docstrings? > I'll have a look at how the Perl bindings for Gtk+ do this (http://gtk2-perl.sourceforge.net/) Does anybody know of other examples?

Re: Perl bindings docstrings Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

On Mon, Jul 8, 2013 at 5:32 PM, Ben Reser wrote: > > So it's as simple as "extract docstring from C header and reformat as > POD". > Actually I meant "So it's NOT as simple...", at least if you want to fully automate this. > Exactly this. We need this documentation. Sometimes we're behind on

Re: subversion.apache.org/docs/swig-py ? Re: Perl bindings docstrings Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

On Tue, Jul 9, 2013 at 4:37 PM, Daniel Shahaf wrote: > Separately, is there a reason the compiled swig-* docs aren't online on > http://subversion.apache.org/docs/, alongside the C and javahl ones? At > least the Perl ones are on CPAN[1], > [1] > http://search.cpan.org/~mschwern/Alien-SVN-v1.7.3.

Problem with Perl bindings?

Hi, I'm investigating a problem with the Perl bindings and it looks as if an APR hash gets corrupted when it's marshalled to/from Perl. Specifically I'm looking at /subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c (from trunk) and the function svn_swig_pl_to_hash. This is the universa

Re: Problem with Perl bindings?

On Wed, Jul 24, 2013 at 2:06 PM, Bert Huijben wrote: > svn_hash_sets() was only introduced a few months ago as an optimized > version for apr_hash_set() for strings. > No, the version using apr_hash_set() has the same problem (in fact I can reliably reproduce this problem in SVN 1.7.10). > Are

Re: Problem with Perl bindings?

Here's how to reproduce my problem (I'm using SVN 1.7.10, but probably any version is affected): Start with a simple command line, e.g. $ svn ls http://svn.apache.org/repos/asf/subversion but that requires some setting in ~/.sunversion/servers to work. E.g. if I'm behind a proxy to the internet,

Re: Problem with Perl bindings?

On Thu, Jul 25, 2013 at 1:19 PM, Philip Martin wrote: > Fixes go on trunk first, and then get backported to 1.8 and 1.7. I can > reproduce the bug on trunk, valgrind shows: > ... > and your patch, modified for trunk, fixes it: > Thanks for the speedy confirmation, Philip. I'm going to commit th

Re: Problem with Perl bindings?

On Thu, Jul 25, 2013 at 1:56 PM, Philip Martin wrote: > apr_pstrmemdup guarantees a null byte. You're right, I was thinking of apr_pmemdup. Cheers, Roderich

[PATCH] speed up svn_repos_authz_check_access

Hi, this patch attempts to speed up svn_repos_authz_check_access, esp. when it is called repeatedly during the same HTTP request (or on the same connection). Subversion issues many HTTP requests that result only in a single call to svn_repos_authz_check_access (i.e. just for the path given in the

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 11:05 AM, Philip Martin wrote: > It would probably better to introduce a new API something like: > > apr_pool_t *svn_config__pool(svn_config_t *); > > declared in subversion/include/private/. > > However I don't fully understand the logic governing the lifetime. The > cache

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 11:05 AM, Philip Martin wrote: > > +svn_boolean_t authz_use_cache = TRUE; /* FIXME devel only */ > > I assume that is temporary, what is the long-term plan? Remove it > completely? > Yes, this will go away. It's just there for benchmarking, so that I can turn caching

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 11:07 AM, Ivan Zhakov wrote: > > For example, when a client uses a long-lived keep-alive connection and > > the authz file changes during the life of that connection, will your > > change cause the changes to be picked up later than they would before > > your patch? > > > W

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 11:02 AM, Daniel Shahaf wrote: > > The patch needs to #include libsvn_subr/config_impl.h > > in order to gain access to svn_config_t.pool: > > the cache (apr_hash_t itself, keys and values) must be allocated from > > the same pool as svn_config_t so that they have the same

Re: [PATCH] speed up svn_repos_authz_check_access

Hi, revised patch attached, hopefully addressing all concerns. No more breaking encapsulation. We simply allocate svn_authz_t from the same pool that svn_config_t is allocated from and remember this pool in a new svn_authz_t member "pool".l Create a function authz_create() for that; it uses apr_p

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 3:59 PM, Ivan Zhakov wrote: > Could you please provide log message for your patch submission [1]. It > makes reviewing patch much easier. > See below. > Did you consider make separate cache_pool and clear if we invoked with > different user? > I revised the patch so tha

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 9:04 PM, Ben Reser wrote: > An attacker can open a connection and starting making requests > to fill up a servers memory. As long as they keep making authz > requests as the same user on the same connection they will be able to > increase the server usage everytime we do a

Re: [PATCH] speed up svn_repos_authz_check_access

On Wed, Aug 7, 2013 at 11:08 PM, Ben Reser wrote: > Yes that's true. I know there are people out there with very large > authz files though. Your cache isn't going to use much extra memory > for most connections. > We could shave off some more if we integrated the cache into svn_config_t. But

Re: [PATCH] speed up svn_repos_authz_check_access

On Friday, August 9, 2013, Philip Martin wrote: > > We could cache the results of authz_parse_line. That would limit the > cache size as it would only grow to the number of sections in the file. > Also authz_parse_line is often the expensive bit as it involves checking > the user against all the

Re: [PATCH] speed up svn_repos_authz_check_access

On Sun, Aug 11, 2013 at 11:17 PM, Philip Martin wrote: > To see the difference consider an authz file with just one block for /. > Given two paths, /foo/bar and /zig/zag, your patch produces two cache > entries. Repeat requests for one of the paths pull the result directly > from the cache. The

"Unable to PUT new contents" - problem with Apache 2.2.25

Hi, we recently upgraded our servers to Apache 2.2.25 and Subversion 1.7.11. Since then several of our users have problems commiting files with blanks somewhere in the pathname. Symptoms are always the same: Apache error_log shows [Tue Aug 27 16:54:27 2013] [error] [client xx.xx.xx.xx] Unable to

Re: "Unable to PUT new contents" - problem with Apache 2.2.25

On Fri, Aug 30, 2013 at 10:49 AM, Julian Foad wrote: > Hi Roderich. Google("Apache 2.2.25 double encoding bug") -> it's a bug in > httpd 2.2.25: . > Ben Reser reported it so hopefully he can tell you any news regarding a > fix, but downgra

Re: Apache Subversion 1.7.13 released

On Friday, August 30, 2013 5:34:34 PM UTC+2, Ben Reser wrote: I'm happy to announce the release of Apache Subversion 1.7.13. > Minor nit: the date of the announcement in the News section of http://subversion.apache.org/ is the same as for 1.7.11. Cheers, Roderich

Re: Apache Subversion 1.7.13 released

On Tue, Sep 3, 2013 at 10:00 AM, Stefan Sperling wrote: > whenever you notice things like this, feel free to apply the obvious > fix rule: > http://subversion.apache.org/docs/community-guide/roles.html#obvious-fix > Thanks, didn't know that - obvious fix applied to index.html and news.html. Che

Re: svn commit: r1553822 - in /subversion/trunk/subversion/bindings/swig: include/svn_types.swg perl/libsvn_swig_perl/swigutil_pl.c perl/libsvn_swig_perl/swigutil_pl.h

On Sat, Dec 28, 2013 at 4:35 PM, Bert Huijben wrote: > While I assume this fixes a real problem... using the *global pool* is > actually introducing a memory leak. The "_global_pool" here is not global pool. In the Perl bindings, it's the - somewhat unfortunate - name given to to the C level va

[PATCH] in-process packed-offset cache broken in 1.6.16 (on 64-bit architectures)

Hi, while looking at strace's of Subversion operations on a repository using packing I noticed the following behavior: 20829 open(".../db/revs/2.pack/pack", O_RDONLY|O_CLOEXEC) = 13 20829 open(".../db/revs/2.pack/manifest", O_RDONLY|O_CLOEXEC) = 14 20829 open(".../db/revs/2.pack/pack", O_RDONLY|O

Re: 1.7.0-beta1 up for testing / signing

On Thu, Jul 21, 2011 at 5:37 PM, Philip Martin wrote: > Thanks!  Could you verify the following patch: Great, works for me with Apache 2.0.64 and APR 0.9.19. Cheers, Roderich

[PATCH] svnmucc doesn't honor --config-dir for auth stuff

Hi, svnmucc doesn't honor option --config-dir when it comes to stuff stored below config_dir/auth. To reproduce: - access a remote repository that will store information below config_dir/auth, e.g. username/password or permanently accepted SSL server certificate, using svn command without --c

Re: FW: Request to pick up fix with revision 1683266 (swig perl typemap update) with next subversion release

On Sunday, July 3, 2016 at 2:22:06 PM UTC+2, Stefan wrote: > I'm not an expert with SWIG and Perl, but from a plain code change point > of view, this fix seems suspicious to also be applicable to the > 1.8-branch, isn't it? You're right. I just nominated it for 1.8. Cheers, Roderich

Re: [PATCH] Perl bindings corrupt "{DATE}" revision variable

On Wed, Nov 2, 2016 at 8:41 PM, Daniel Shahaf wrote: > Thanks, Roderich. Could you update the log message with an appropriate > "Verbed by"[1] clause, for contribulyzer? > Done. > I assume this should be backported, in which case, here is my +0 for > backport of the patch as committed. > > No

Re: [PATCH] Perl bindings corrupt "{DATE}" revision variable

On Thu, Nov 3, 2016 at 10:27 AM, Bert Huijben wrote: > I’m not sure about the perl rules applied around this function, but > perhaps we should just copy the string instead of changing memory that we > receive as constant. We might also have a different api function that > behaves in a cleaner way

Re: svn commit: r1648853 - in /subversion/trunk/subversion/bindings/swig/perl/native: Client.pm Repos.pm t/1repos.t t/3client.t

On Thu, Jan 1, 2015 at 7:00 PM, Bert Huijben wrote: > It looks like this test needs a bit of fixup before it supports running > the tests in debug mode. > > In most cases it is easier to test for the error code than for the text. > (The error text of our API calls is localized) > Fixed in r16489

Re: Segfault in Perl bindings when commit touches a large number of files

On Monday, March 23, 2015 at 1:35:49 PM UTC+1, Philip Martin wrote: > Philip Martin writes: > > > I'm not familiar with this code, but looking at other code in the file I > > tried this: > > > > Index: ../src-1.9/subversion/bindings/swig/include/svn_types.swg > > =

Weird bug with directory deltification in 1.8.x

Hi, found in the wild, reproducible with this script: -- # cleanup previous experiments rm -rf repo import url=file://$PWD/repo svnadmin create --compatible-version 1.8 repo cat > repo/db/fsfs.conf < foo.txt echo bar > bar.txt mkdir -p directory-with-a-longish-name svn im

Re: Weird bug with directory deltification in 1.8.x

On Wed, Apr 29, 2015 at 6:54 AM, Stefan Fuhrmann < stefan.fuhrm...@wandisco.com> wrote: > Fixed in r1676667. Details, regression test & backport tomorrow. > Thanks for the speedy fix. From the log message of r1676667 So, this fixes a data re-construction bug, not a repo corruption. > That's a g

Re: Segfault in Perl bindings when commit touches a large number of files

On Wed, May 20, 2015 at 6:19 AM, James McCoy wrote: > I'm still experiencing the crash in 1.9.0-rc1 unless I apply the > original change I suggested to the generated > subversion/bindings/swig/perl/native/svn_delta.c. I'm not sure how that > specific part of the file is generated, so I'll just a

Re: Segfault in Perl bindings when commit touches a large number of files

On Wed, May 20, 2015 at 10:12 AM, Roderich Schupp wrote: > Looking at your patch, the offending line may very well be the cause of > the crash: Nope, I'll take that back. When this line ST(argvi) = sv_newmortal(); is called argvi is still 0, so it is safe. This line is actual

Re: Segfault in Perl bindings when commit touches a large number of files

On Fri, May 22, 2015 at 6:07 PM, Philip Martin wrote: > It would help if I built the correct tree. No, that is not enough, the > regression tests fail. > No surprise here: (1) Your patch simply means: ignore the result_digest, but also produce no return value for it. But users of the Perl wrap

Re: Segfault in Perl bindings when commit touches a large number of files

On Fri, May 22, 2015 at 6:25 PM, Roderich Schupp wrote: > > But I'm not entirely convinced that the bug is really in the construction > of the magical md5sum. > Maybe git-svn is to blame, perhaps a problem with the lifetime of the > pools it uses... > I just modi

Re: Segfault in Perl bindings when commit touches a large number of files

On Sun, May 24, 2015 at 2:51 AM, James McCoy wrote: > The patch is working for me as well. > I've dug a little deeper and think I've found a serious flaw in how the Perl bindings handle the Perl arguments and return values stack. Swig generates for Perl what is known (in the Perl world) as XS c

Re: Segfault in Perl bindings when commit touches a large number of files

On Wed, May 27, 2015 at 7:56 PM, Roderich Schupp wrote: > I've dug a little deeper and think I've found a serious flaw in how the > Perl bindings handle > the Perl arguments and return values stack. > I've committed a series of patches (r1683261:1683271) to address t

Re: Segfault in Perl bindings when commit touches a large number of files

On Wed, Jun 3, 2015 at 5:54 PM, Roderich Schupp wrote: > On Wed, May 27, 2015 at 7:56 PM, Roderich Schupp < > roderich.sch...@gmail.com> wrote: > >> I've dug a little deeper and think I've found a serious flaw in how the >> Perl bindings handle >>