You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2010/02/21 10:49:38 UTC
serf crash
Hi,
I accidentally ended up using ra_serf today (have been using ra_neon
mostly cause ra_serf has been quite unstable). And, surprise,
it promptly crashed on me in all its glory. See below.
Note that the trunk build I was using was a bit outdated (ca. 19th of
December 2009), so this may have been fixed since.
Stefan
A subversion/bindings/javahl/src/org/apache/subversion/javahl/callback/ChangelistCallback.java
A subversion/bindings/javahl/src/org/apache/subversion/javahl/callback/UserPasswordCallback.java
U subversion/libsvn_subr/md5.c
U subversion/libsvn_subr/opt.c
U subversion/libsvn_subr/win32_crypto.c
subversion/svn/update-cmd.c:97: (apr_err=54)
subversion/libsvn_client/update.c:365: (apr_err=54)
subversion/libsvn_client/update.c:284: (apr_err=54)
subversion/libsvn_wc/deprecated.c:149: (apr_err=54)
subversion/libsvn_ra_serf/update.c:2241: (apr_err=54)
svn: Error retrieving REPORT (54): Connection reset by peer
Segmentation fault (core dumped)
#0 cancel_request (request=0x20eac04b8, list=0x2063fb078, notify_request=0) at context.c:440
440 serf_debug__closed_conn(request->req_bkt->allocator);
(gdb) bt
#0 cancel_request (request=0x20eac04b8, list=0x2063fb078, notify_request=0) at context.c:440
#1 0x000000020bcb46fd in serf_connection_close (conn=0x2063fb028) at context.c:1249
#2 0x000000020bcb34b9 in clean_conn (data=0x20eac04b8) at context.c:184
#3 0x000000020eb015cd in run_cleanups (cref=0x204b31048)
at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:2314
#4 0x000000020eb00b54 in apr_pool_destroy (pool=0x204b31028)
at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:782
#5 0x000000020eb00bc5 in apr_pool_destroy (pool=0x205c05028)
at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:779
#6 0x000000020eb00bc5 in apr_pool_destroy (pool=0x20075d028)
at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:779
#7 0x00000000004133e0 in main (argc=2, argv=0x7f7ffffe44b8) at subversion/svn/main.c:2231
(gdb)
(gdb) p request->req_bkt->allocator
Cannot access memory at address 0x20b0e4148
(gdb) p request->req_bkt
$1 = (serf_bucket_t *) 0x20b0e4138
(gdb) p *request->req_bkt
Cannot access memory at address 0x20b0e4138
(gdb) p *request
$2 = {conn = 0x2063fb028, respool = 0x0, allocator = 0x20cce00a8, req_bkt = 0x20b0e4138, setup = 0,
setup_baton = 0x2021760b0, acceptor = 0x20375409d <svn_ra_serf__accept_response>,
acceptor_baton = 0x20b04f2d0, handler = 0x203755983 <handle_response>, handler_baton = 0x2021760b0,
resp_bkt = 0x0, next = 0x20eac0538}
(gdb)
Re: serf crash
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Feb 21, 2010 at 07:22:36AM -0800, Justin Erenkrantz wrote:
> On Sun, Feb 21, 2010 at 2:49 AM, Stefan Sperling <st...@elego.de> wrote:
> > Hi,
> >
> > I accidentally ended up using ra_serf today (have been using ra_neon
> > mostly cause ra_serf has been quite unstable). And, surprise,
> > it promptly crashed on me in all its glory. See below.
> >
> > Note that the trunk build I was using was a bit outdated (ca. 19th of
> > December 2009), so this may have been fixed since.
>
> Trunk of what?
Of svn.
> Are you using serf 0.3.1? -- justin
Using serf 0.3.0.
Stefan
Re: serf crash
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Feb 21, 2010 at 2:49 AM, Stefan Sperling <st...@elego.de> wrote:
> Hi,
>
> I accidentally ended up using ra_serf today (have been using ra_neon
> mostly cause ra_serf has been quite unstable). And, surprise,
> it promptly crashed on me in all its glory. See below.
>
> Note that the trunk build I was using was a bit outdated (ca. 19th of
> December 2009), so this may have been fixed since.
Trunk of what?
Are you using serf 0.3.1? -- justin
Re: serf crash
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> Segmentation fault (core dumped)
> #0 cancel_request (request=0x20eac04b8, list=0x2063fb078, notify_request=0) at context.c:440
> 440 serf_debug__closed_conn(request->req_bkt->allocator);
> (gdb) bt
> #0 cancel_request (request=0x20eac04b8, list=0x2063fb078, notify_request=0) at context.c:440
> #1 0x000000020bcb46fd in serf_connection_close (conn=0x2063fb028) at context.c:1249
> #2 0x000000020bcb34b9 in clean_conn (data=0x20eac04b8) at context.c:184
> #3 0x000000020eb015cd in run_cleanups (cref=0x204b31048)
> at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:2314
> #4 0x000000020eb00b54 in apr_pool_destroy (pool=0x204b31028)
> at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:782
> #5 0x000000020eb00bc5 in apr_pool_destroy (pool=0x205c05028)
> at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:779
> #6 0x000000020eb00bc5 in apr_pool_destroy (pool=0x20075d028)
> at /home/stsp/svn/src/apr-1.3.8/memory/unix/apr_pools.c:779
> #7 0x00000000004133e0 in main (argc=2, argv=0x7f7ffffe44b8) at subversion/svn/main.c:2231
Looks like this problem:
http://svn.haxx.se/dev/archive-2010-02/0139.shtml
using memory after it has been free'd.
--
Philip