Dmitry Batrak writes:
> The following command:
>
> svn log
> https://svn.apache.org/repos/asf/subversion/branches/gnome-keyring/subversion/bindings/javahl@871338
> -r 870558:871338 -g
>
> returns a number of irrelevant revisions (in particular, 870728,
> 870496, 869828) in the 'main' line of the
$ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
==15971== Invalid read of size 1
==15971==at 0x4C25CF3: strncmp (mc_replace_strmem.c:398)
==15971==by 0x652BA6A: svn_fs_bdb__locks_get (locks-table.c:257)
==15971==by 0x653A0F0: txn_body_get_locks (lock.c:440)
==15971==by 0x654125E:
Philip Martin writes:
> $ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
> ==15971== Invalid read of size 1
I've fixed this particular case by r1205839 with an early return. I
also committed r1205848 which I think fixes the underlying problem.
--
uberSVN: Apache Subversion Made Easy
http://w
On 11/24/2011 09:39 AM, Philip Martin wrote:
> Philip Martin writes:
>
>> $ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
>> ==15971== Invalid read of size 1
>
> I've fixed this particular case by r1205839 with an early return. I
> also committed r1205848 which I think fixes the underlying pr
"C. Michael Pilato" writes:
> On 11/24/2011 09:39 AM, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> $ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
>>> ==15971== Invalid read of size 1
>>
>> I've fixed this particular case by r1205839 with an early return. I
>> also committed r120584
On Tue, Nov 22, 2011 at 10:17 AM, Alexander Kitaev wrote:
> Hello All,
>
> Let me introduce our new project: SubGit (http://subgit.com/).
> SubGit is a free tool for smooth migration from Subversion to Git. As
> well as from Git to Subversion. Without git-svn insanity.
> It works like this:
You'v
Philip Martin writes:
> I'm not 100%
> sure whether we need second one as well as the first one: I suspect that
> the first alone is not enough, but so far I've failed to come up with a
> test case to prove that.
I can't get valgrind to trigger but if I extend the test case like this:
Index: su
Hello,
My distro is a full multilib capable system, it has 32-bits libs in /lib
and /usr/lib and 64-bit libs in /lib64 and /usr/lib64. Subversion build
system has never complained before, as I have an exotic multilib distro
but it now fails (1.7.1), especially the 32-bit build :
Below are th
appzer0 writes:
> + LDFLAGS='-L/usr/lib -L/lib'
Why?
> libtool: install: (cd /tmp/subversion-1.7.1/subversion/libsvn_delta;
> /bin/sh /tmp/subversion-1.7.1/libtool --tag CC --silent --mode=relink
> gcc -m32 -O2 -march=i686 -pipe -pthread -D_LARGEFILE64_SOURCE -DNE_LFS
> -Werror=implicit-functi
svn_fs_base__retry_txn() is a while(1) loop that calls
begin_trail(pool) in every iteration. The latter function callocates
a struct trail_t out of POOL.
Is there a memory growth issue here? Will the number of iterations of
the while(1) loop be small or bounded? If not, should we avoid repeated
I took the liberty to clarify the purpose of contrib/client-side/emacs/
vc-svn.el - to provide for a working vc-mode in Emacs 21 - since it
has occasionally been used when it shouldn't, confusing the user. The
file now also clearly states that new development should go in the
Emacs tree inst
While reviewing r1205726 I came across this pearl:
reps-strings.c- /* Make a list of all the rep's we need to undeltify
this range.
reps-strings.c- We'll have to read them within this trail anyway,
so we might
reps-strings.c- as well do it once and up front. */
r
cmpil...@apache.org wrote on Thu, Nov 24, 2011 at 05:45:25 -:
> Author: cmpilato
> Date: Thu Nov 24 05:45:24 2011
> New Revision: 1205726
>
> URL: http://svn.apache.org/viewvc?rev=1205726&view=rev
> Log:
> Plug a memory leak in the fs-base deltification logic. Twice in a
> decade I've seen th
On Thu, Nov 24, 2011 at 4:00 PM, Daniel Shahaf wrote:
> While reviewing r1205726 I came across this pearl:
>
> reps-strings.c- /* Make a list of all the rep's we need to
> undeltify this range.
> reps-strings.c- We'll have to read them within this trail
> anyway, so we might
+ LDFLAGS='-L/usr/lib -L/lib'
Why?
Because all of the 32-bit libs are in /lib and /usr/lib. The native
64-bit libs are in /lib64 and /usr/lib64 (which is the system default).
The system is fully multilib, i686 and x86_64 on a running 64-bit system.
If you rerun the libtool command with --sile
15 matches
Mail list logo
