Package: webdis
Version: 0.1.1-2
Severity: serious
Hello, I'm trying to transition the hiredis package from libhiredis0.10 to
libhiredis0.13, but some issues with the packaging (specifically the
vendored sources) of webdis are causing me some problems. Specifically, the
vendored hiredis and jansson headers are used instead of the headers from
libhiredis-dev and libjansson-dev.
The most noisy symptom is a segfault when building webdis against
libhiredis0.13, which gdb shows is pool_connect trying to call strlen(...)
on a null pointer:
(gdb) set follow-fork-mode child
(gdb) run /tmp/tmp.swHGJysNL5/webdis.json
Starting program: /home/tom/Source/debian/webdis-0.1.1/webdis
/tmp/tmp.swHGJysNL5/webdis.json
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New process 25152]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6585700 (LWP 25153)]
[New Thread 0x7ffff5d84700 (LWP 25154)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6585700 (LWP 25153)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x000000000040798f in pool_connect (p=0x623940, db_num=0,
attach=attach@entry=1) at pool.c:134
#2 0x00000000004031a3 in worker_pool_connect (w=0x623b70, w=0x623b70) at
worker.c:133
#3 worker_main (p=0x623b70) at worker.c:153
#4 0x00007ffff715a0a4 in start_thread (arg=0x7ffff6585700) at
pthread_create.c:309
#5 0x00007ffff6e8f04d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Stepping through gdb a little more carefully, we can trace the issue down
to the call out to redisAsyncConnectUnix in pool_connect.
Inside redisAsyncConnectUnix (all the way up until the final retq
instruction on amd64) the redisAsyncContext looks something like this:
> p *ac
$4 = {c = {err = 1, errstr = "No such file or directory", '\000' <repeats
102 times>, fd = -1, flags = 0,
obuf = 0x7ffff0000f68 "", reader = 0x7ffff0000f80, connection_type =
REDIS_CONN_UNIX, timeout = 0x0, tcp = {
host = 0x0, source_addr = 0x0, port = 0}, unix_sock = {
path = 0x7ffff00008c0 "/tmp/tmp.ltIFMqN271/redis.sock"}}, err = 1,
errstr = 0x7ffff00011e4 "No such file or directory", data = 0x0, ev =
{data = 0x0, addRead = 0x0, delRead = 0x0,
addWrite = 0x0, delWrite = 0x0, cleanup = 0x0}, onDisconnect = 0x0,
onConnect = 0x0, replies = {head = 0x0,
tail = 0x0}, sub = {invalid = {head = 0x0, tail = 0x0}, channels =
0x7ffff0000e80, patterns = 0x7ffff0000ec0}}
*The moment the retq instruction in this function returns* the struct
layout changes in gdb (e.g. the connection_type field disappears):
> p *ac
$6 = {c = {err = 1, errstr = "No such file or directory", '\000' <repeats
102 times>, fd = -1, flags = 0,
obuf = 0x7ffff0000f68 "", reader = 0x7ffff0000f80}, err = 1, errstr =
0x0, data = 0x0, ev = {data = 0x0,
addRead = 0x0, delRead = 0x7ffff00008c0, addWrite = 0x1, delWrite =
0x7ffff00011e4, cleanup = 0x0},
onDisconnect = 0x0, onConnect = 0x0, replies = {head = 0x0, tail = 0x0},
sub = {invalid = {head = 0x0, tail = 0x0},
channels = 0x0, patterns = 0x0}}
So the layout of the redisContext struct used to build libhiredis-dev
0.13.1-1 differs from one used to build webdis. This can be explained by
the vendored headers & can be further verified with strace when building
the package with gbp:
$ strace -e open -f -o ../strace.txt gbp buildpackage
--git-debian-branch=debian --git-upstream-branch=master
Any possibility you could sort that out? If it were up to me I'd use a
patch to blow away the vendored sources, but I'm not sure if that's the
best way to handle this sort of situation. gbp's support for filtering may
also be an option.
libhiredis0.13 and libhiredis-dev 0.13.1-1 have been uploaded to the
experimental distribution if you'd like to reproduce this for yourself.
Cheers,
Tom
--
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
