On 04/16/2012 02:16 AM, Julian Foad wrote:
Blair Zajac wrote:
On 04/13/2012 12:45 AM, Julian Foad wrote:
Blair Zajac wrote:
Having the empty files, such as changes, is that odd? Could that be a
hint?
No, that's not interesting, that's just the result of crashing out
at the point where
Blair Zajac wrote:
> On 04/13/2012 12:45 AM, Julian Foad wrote:
>> Blair Zajac wrote:
>>> Having the empty files, such as changes, is that odd? Could that be a
>>> hint?
>>
>> No, that's not interesting, that's just the result of crashing out
>> at the point where it did -- in the middle of
On 04/13/2012 06:33 PM, Daniel Shahaf wrote:
Blair Zajac wrote on Fri, Apr 13, 2012 at 13:08:12 -0700:
To do valgrind well, do I need to recompile APR with specific flags to
enable pool debugging?
Other than --enable-pool-debugging=N (aka -DAPR_POOL_DEBUG=N) (where
N is placeholder for a numb
Blair Zajac wrote on Fri, Apr 13, 2012 at 13:08:12 -0700:
> To do valgrind well, do I need to recompile APR with specific flags to
> enable pool debugging?
>
Other than --enable-pool-debugging=N (aka -DAPR_POOL_DEBUG=N) (where
N is placeholder for a number) ?
On 04/13/2012 12:45 AM, Julian Foad wrote:
Blair Zajac wrote:
Since we discussed this, we moved the Subversion server to a new box and
from RAID to FusionIO storage and we're still getting the core dumps
with the same stack trace, so I don't think its memory corruption.
I meant I suspect corr
Blair Zajac wrote:
> Since we discussed this, we moved the Subversion server to a new box and
> from RAID to FusionIO storage and we're still getting the core dumps
> with the same stack trace, so I don't think its memory corruption.
I meant I suspect corruption of this process's state by any m
On 08/04/2010 09:32 AM, Blair Zajac wrote:
On 08/04/2010 05:38 AM, Julian Foad wrote:
Again due to in-lining, I presume, fs_fs.c:2859 calls svn_checksum_dup()
but the debugger shows, in this case, only its subroutine
svn_checksum__from_digest().
#0 0x2ac15f8bd28c in svn_checksum__from_dige
On 08/04/2010 05:38 AM, Julian Foad wrote:
Hi Blair. I had a look but can't see how this can occur.
On Sat, 2010-07-31, Blair Zajac wrote:
We run long running, persistent processes that expose the svn_fs and svn_repos
APIs via RPC (using ZeroC's Ice). We've seen some occasional core dumps aft
Hi Blair. I had a look but can't see how this can occur.
On Sat, 2010-07-31, Blair Zajac wrote:
> We run long running, persistent processes that expose the svn_fs and
> svn_repos
> APIs via RPC (using ZeroC's Ice). We've seen some occasional core dumps
> after
> the processes have been up fo
We run long running, persistent processes that expose the svn_fs and svn_repos
APIs via RPC (using ZeroC's Ice). We've seen some occasional core dumps after
the processes have been up for two weeks or more. We're running against 1.6.5.
The processes have LRU caches of fs_t and repos_t that th
10 matches
Mail list logo