alex1818 / serf

Automatically exported from code.google.com/p/serf
Apache License 2.0
0 stars 0 forks source link

Serf trunk: Segmentation fault in test suite #158

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Test suite in Serf trunk (r2445) fails in the following way:

$ gdb --args test/test_all
GNU gdb (Gentoo 7.8.1 vanilla) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test/test_all...done.
(gdb) r
Starting program: /tmp/serf/test/test_all 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
serf_config_get_object (config=config@entry=0xa0d0a0d, key=key@entry=268435457, 
value=value@entry=0x7fffffffcc90) at config_store.c:270
270             target = config->per_context;
(gdb) bt
#0  serf_config_get_object (config=config@entry=0xa0d0a0d, 
key=key@entry=268435457, value=value@entry=0x7fffffffcc90) at config_store.c:270
#1  0x00007ffff7bc6ec0 in serf__log (level=level@entry=8, comp=comp@entry=4, 
prefix=0x7ffff7bd3dd3 "receiving raw", config=0xa0d0a0d, 
    fmt=fmt@entry=0x7ffff7bd486d "--- %d bytes. --\n") at logging.c:146
#2  0x00007ffff7bcd799 in serf_log_wrapped_readline (bucket=<optimized out>, 
acceptable=<optimized out>, found=<optimized out>, data=0x7fffffffce10, 
    len=0x7fffffffce18) at buckets/log_wrapper_buckets.c:56
#3  0x000000000041055f in serf_mock_sock_readline (bucket=<optimized out>, 
acceptable=<optimized out>, found=<optimized out>, data=<optimized out>, 
    len=<optimized out>) at test/mock_sock_buckets.c:44
#4  0x00007ffff7bcacc5 in serf_linebuf_fetch 
(linebuf=linebuf@entry=0x7ffff7f5e078, bucket=0x7ffff7f902b8, 
acceptable=acceptable@entry=7)
    at buckets/buckets.c:512
#5  0x00007ffff7bce51e in fetch_line (acceptable=7, ctx=0x7ffff7f5e038) at 
buckets/response_buckets.c:124
#6  run_machine (ctx=ctx@entry=0x7ffff7f5e038, bkt=<optimized out>) at 
buckets/response_buckets.c:224
#7  0x00007ffff7bce90b in wait_for_body (ctx=0x7ffff7f5e038, 
bkt=0x7ffff7f90438) at buckets/response_buckets.c:354
#8  serf_response_read (bucket=0x7ffff7f90438, requested=2048, 
data=0x7fffffffced0, len=0x7fffffffced8) at buckets/response_buckets.c:413
#9  0x00000000004060a3 in handle_response (request=<optimized out>, 
response=0x7ffff7f90438, handler_baton=0x7fffffffd070, pool=<optimized out>)
    at test/test_util.c:244
#10 0x00007ffff7bc89c1 in handle_response (pool=<optimized out>, 
request=0x7ffff7f3a038) at outgoing.c:1049
#11 read_from_connection (conn=0x7ffff7fc8028) at outgoing.c:1249
#12 serf__process_connection (conn=conn@entry=0x7ffff7fc8028, events=<optimized 
out>) at outgoing.c:1399
#13 0x00007ffff7bc6586 in serf_event_trigger (s=s@entry=0x7ffff7fed2b8, 
serf_baton=<optimized out>, desc=<optimized out>) at context.c:233
#14 0x00007ffff7bc6689 in serf_context_run (ctx=0x7ffff7fed2b8, 
duration=duration@entry=0, pool=<optimized out>) at context.c:307
#15 0x0000000000406816 in run_client_and_mock_servers_loops 
(tb=tb@entry=0x7ffff7fed0b0, num_requests=num_requests@entry=10, 
    handler_ctx=handler_ctx@entry=0x7fffffffd070, pool=<optimized out>) at test/test_util.c:504
#16 0x000000000040907a in send_more_requests_than_keepalive_of_server 
(tc=0x62b4e0) at test/test_context.c:226
#17 0x00000000004054e2 in CuTestRun (tc=tc@entry=0x62b4e0) at test/CuTest.c:173
#18 0x0000000000405b7c in CuSuiteRun (testSuite=testSuite@entry=0x627210) at 
test/CuTest.c:357
#19 0x0000000000404dca in main (argc=<optimized out>, argv=<optimized out>) at 
test/test_all.c:96
(gdb) print config
$1 = (serf_config_t *) 0xa0d0a0d
(gdb) print config->per_context
Cannot access memory at address 0xa0d0a1d

Original issue reported on code.google.com by Arfrever...@gmail.com on 5 Nov 2014 at 1:18

GoogleCodeExporter commented 9 years ago
I get the same on GNU/Linux (openSUSE), reported previously on the mailing list:
https://groups.google.com/d/msg/serf-dev/2FezLfxgHvE/SKS313rBOY4J

Original comment by andreas.stieger@gmx.de on 5 Nov 2014 at 1:44

GoogleCodeExporter commented 9 years ago
No longer occurs as of trunk@2474

Original comment by andreas.stieger@gmx.de on 22 Jan 2015 at 8:43

GoogleCodeExporter commented 9 years ago
The root cause was identified by Philip Martin (see mails to serf and 
subversion dev lists).

I applied his patch in r2466, and fixed a few similar cases in r2467. Thanks 
for closing this issue.

Original comment by b...@qqmail.nl on 22 Jan 2015 at 9:10