Your message dated Sun, 19 Jul 2015 17:05:53 +0000 with message-id <[email protected]> and subject line Bug#785476: fixed in webdis 0.1.1-2.1 has caused the Debian Bug report #785476, regarding segfault when building against libhiredis0.13 due to vendored header files to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 785476: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785476 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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>
--- End Message ---
--- Begin Message ---Source: webdis Source-Version: 0.1.1-2.1 We believe that the bug you reported is fixed in the latest version of webdis, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Cyril Brulebois <[email protected]> (supplier of updated webdis package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Tue, 14 Jul 2015 18:32:13 +0200 Source: webdis Binary: webdis webdis-dbg Architecture: source Version: 0.1.1-2.1 Distribution: unstable Urgency: medium Maintainer: Andriy Senkovych <[email protected]> Changed-By: Cyril Brulebois <[email protected]> Description: webdis - simple web server providing an HTTP interface to Redis webdis-dbg - webdis debugging symbols Closes: 785476 Changes: webdis (0.1.1-2.1) unstable; urgency=medium . * Non-maintainer upload. * Remove embedded code copies (hiredis, jansson) in the clean target to make sure not to use them; this notably fixes the FTBFS during the libhiredis0.10 → libhiredis0.13 transition (Closes: #785476). Checksums-Sha1: e726bb813b6d5a027f6d30983eee3fb1b3eb812d 2038 webdis_0.1.1-2.1.dsc 86203b05328d332484c5cc1b0012990910d8c182 9784 webdis_0.1.1-2.1.debian.tar.xz Checksums-Sha256: d0f6c3d655a8a15f3335569a07e0bfe77968a3bf683590ab0ab3ba9d3ef5b516 2038 webdis_0.1.1-2.1.dsc fecfba8a67cc311e84e852fb9ccf7f183f5dab01b43539886b2306a0a39c3cb9 9784 webdis_0.1.1-2.1.debian.tar.xz Files: 5f64681b99f9c572a7a1cd0385265927 2038 web optional webdis_0.1.1-2.1.dsc b26f999f71c99da3d680719df5fb0c89 9784 web optional webdis_0.1.1-2.1.debian.tar.xz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVpTnVAAoJEP+RSvDCs1UgKqMP/i3n54/L+dplHO99eZPLvxJ8 BtpFyXqOvOz34V2ivELjcMQjWUDTLemxWy4R62bkxlfYVYV9312tURyCOJiHrNPP UdxJl3DwxzlAfHYZw4vStdrRamwq+pwObKrx19H+TgXqVGer/URxyx246fHC+li+ GRuzykPl9oJ0EGsLDvHcmU5PMchH92B0A8DrxLjesI79XGjEEOwfMRu35fRoHEJ4 mZrWeahTSc8Kriajh+5adEUEWZ3xR6WP6JrN33GYABoqvARRWNCPIdTKlMFvElsR yitfmfX+J4eX2kRIqklNytUX0gPmwBuKNd5hgRvFGYwcsT/915nJ5Q0ccq5A3ob2 +JKBh5xDBEZb2IsRFD94N3BOfKjz50IsxbUV1sm1RCNZX98EymESks3Zq6lhMUKp SbJ0dCROP+zyzdpWSmer2crey27RS0tp8HsaMkjXlRcaK77KNxanFemRioSVeITv 4GECC2p8BCvlFPF/7QPAWtJXdM4/MnSOrx2G0Z+e9grybKjswdB7bKvHR1APhy8L nNsN1L1rt9/PQB6jRMVkw0pGmDJpCHFYUrLQi9gNQyzxSG//55wewn9Be37C232F N8RcfYEOwS9IO/qXFuIx5BP0DXpxGIexAUOnx9Lna/eRC5S2dfRDV7ssYVvLGJl8 Z0vgHo/g3UKGobVVkGie =7hlv -----END PGP SIGNATURE-----
--- End Message ---
