[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: crash in server

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-04-07 19:40:24 CEST

"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

This is an archived mail posted to the Subversion Dev mailing list.