"SteveKing" <steveking@gmx.ch> writes:
> when using the svn client with the newest revision (5573)
> it's possible to crash the server (version 0.20.1):
>
> svn log -v -r2:0 TestWC
>
> this crashes the server.
>
> If the server has version 0.18 it won't crash. Also, it doesn't
> crash if the revisions are given in form -r0:2.
> (Server and Client running on WinXP).
>
> I'm not familiar with the server and how to debug it so I can't
> help you here with stacktraces or dumps. But I hope that
> someone else can reproduce that.
Thanks. (Next time please say which RA layer, though.)
I've just reproduced this with ra_dav, so no need now. The bug is
mysterious so far. Here is the stacktrace. I got this by shutting
downn Apache2, then restarting with the -X flag under gdb, to get one
process:
$ gdb /usr/local/apache2/bin/httpd
(gdb) break main
(gdb) run -X
^C
[gdb stops the process temporarily, now all symbols are loaded]
(gdb) continue
[now run the command, wait for segfault]
(gdb) where
#0 0x4007636b in apr_hash_next (hi=0x8178060) at apr_hash.c:155
#1 0x400763d9 in apr_hash_first (p=0x0, ht=0x8178060) at apr_hash.c:173
#2 0x40125bdd in log_receiver (baton=0xbffff7f0, changed_paths=0x8178060,
rev=0, author=0x0, date=0x81822c0 "2003-04-07T19:52:50.147982Z", msg=0x0,
pool=0x8177ff8) at subversion/mod_dav_svn/log.c:117
#3 0x4003148c in svn_repos_get_logs (repos=0x8168660, paths=0x8168a50,
start=2, end=0, discover_changed_paths=1, strict_node_history=0,
receiver=0x40125b02 <log_receiver>, receiver_baton=0xbffff7f0,
pool=0x8164350) at subversion/libsvn_repos/log.c:217
#4 0x40126025 in dav_svn__log_report (resource=0x81683e8, doc=0x8166098,
output=0x8164fd0) at subversion/mod_dav_svn/log.c:278
#5 0x4012dc78 in dav_svn_deliver_report (r=0x8164388, resource=0x81683e8,
doc=0x8166098, output=0x8164fd0) at subversion/mod_dav_svn/version.c:775
#6 0x08072955 in dav_method_report (r=0x8178060) at mod_dav.c:3959
#7 0x08089db6 in ap_run_handler (r=0x8164388) at config.c:195
#8 0x0808a2ce in ap_invoke_handler (r=0x8164388) at config.c:401
#9 0x0806c85f in ap_process_request (r=0x8164388) at http_request.c:288
#10 0x080689e9 in ap_process_http_connection (c=0x815fc90) at http_core.c:293
#11 0x08092a46 in ap_run_process_connection (c=0x815fc90) at connection.c:85
#12 0x0808896c in child_main (child_num_arg=0) at prefork.c:696
#13 0x08088b16 in make_child (s=0x80cab30, slot=0) at prefork.c:736
#14 0x08088b6f in startup_children (number_to_start=5) at prefork.c:808
#15 0x08089261 in ap_mpm_run (_pconf=0x8088248, plog=0x81060e8, s=0x80cab30)
at prefork.c:1024
#16 0x0808dfee in main (argc=2, argv=0xbffffaf4) at main.c:660
#17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
That's here, right on the arrow:
APR_DECLARE(apr_hash_index_t *) apr_hash_next(apr_hash_index_t *hi)
{
hi->this = hi->next;
while (!hi->this) {
if (hi->index > hi->ht->max)
return NULL;
=====> hi->this = hi->ht->array[hi->index++];
}
hi->next = hi->this->next;
return hi;
}
And take a look at this:
(gdb) p *(hi->ht)
$8 = {pool = 0x8178060, array = 0x0, iterator = {ht = 0x0, this = 0x0,
next = 0x0, index = 16}, count = 20, max = 31}
(gdb)
That doesn't look like a healthy hash table to me :-) !
I popped up to the frame in svn_repos_get_logs(). The relevant swath
of code is near the end of that function:
if ((this_rev > 0) && discover_changed_paths)
{
svn_fs_root_t *newroot;
changed_paths = apr_hash_make (subpool);
SVN_ERR (svn_fs_revision_root (&newroot, fs, this_rev, subpool));
SVN_ERR (detect_changed (changed_paths, newroot, subpool));
}
SVN_ERR ((*receiver) (receiver_baton,
(discover_changed_paths ? changed_paths : NULL),
this_rev,
author ? author->data : NULL,
date ? date->data : NULL,
message ? message->data : NULL,
subpool));
(It's using a subpool because it's looping over log messages, of
course.)
And that's all I know right now; don't know yet why/how changed_paths
is screwed up. Working on it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 7 20:23:18 2003