cmpilato@collab.net wrote:
> So, I was trying to figure out why my use of `svnadmin dump
> <path_to_a_copy_of_the_svn_repos> 278 300' was core-dumping while
> processing revision 278, and gdb showed me this (note the, uh, 471
> layers of recursion on rep_read_range). Branko? Are you out there?
> Help?!
>
> There's nothing suspect about the place where the code dumped core.
> Just a call to svn_pool_create() ... of course, it was really weird
> to be able, in gdb, to *literally* successfully print the contents of
> trail->pool->child->sibling->sibling->sibling->sibling->sibling->sibling
> ->sibling->sibling->sibling->sibling->sibling->sibling->sibling->sibling
> ... (give or take a few "->sibling"'s). But I wonder if perhaps the
> code was dying by hitting a stack limitation. Does Linux have such a
> limitation (besides, of course, system resources) ?
In pthreads under Linux, I know there is a 2MB limit on stack size, at least I
remember reading that on the lkml when discussing the maximum number of threads
that being a limiting factor.
On linux, you set the stack limit in a variety of ways including using you're
shell. With bash, ulimit -a will show it to you. If you want to know that fact
programmatically, getrlimit, getrusage should do the job. I believe that would
be a POSIX and/or Single UNIX Specification thing. Don't bet the farm on that
fact however.
Oh yeah, cool stack trace. I would be curious what an strace of that comes up
with, I'll bet you're in the middle of calling brk, or sbrk when attempting to
allocate more vm when bad things start happening.
Also, you can core dump for a lot of reasons, was it Sig 11 (SEGV) in this case?
Kirby
>
> Another weird thing is that I *can* successfully check out revision
> 278.
>
> Anys, here's the stack:
>
> (gdb) where
> #0 0x8054a57 in rep_read_range (fs=0x807ced8, rep_key=0x923ea30 "ig9",
> buf=0x9270088 "", offset=0, len=0xbfe02fdc, trail=0x8387b50)
> at subversion/libsvn_fs/reps-strings.c:450
[snip]
> #1889 0x804d1f1 in svn_repos_dump_fs (repos=0x8078f48, stream=0x8079110,
> start_rev=278, end_rev=300, pool=0x8078df8)
> at subversion/libsvn_repos/dump.c:661
> #1890 0x804aebc in main (argc=5, argv=0xbffffb7c)
> at subversion/svnadmin/main.c:481
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 29 01:36:09 2002