On Tue, Jan 5, 2016 at 6:54 AM, Jeremie Le Hen <j...@freebsd.org> wrote: > Hi, > > Yeah... when you read that subject you probably had this weird gaze ô_Ò > like I did when I came to that conclusion.
Theo will probably get after me for responding when I don't know what I'm talking about, and I don't have specific experience with this package, but it's not unusual, in general. Stripping symbols can reveal lots of things where prorammers have cut corners or just made mistakes -- pointer issues are especially prominent but not the only problems. However, in this case, I'm guessing it would probably not be pointer issues so much as something like allocation class issues that are hidden when the symbols are left in, but exposed when the symbols are stripped. That said, you may not want to think too hard about that just yet. > I've been experiencing segfaults in milter-greylist on one of my MX > running OpenBSD for a while. I contacted Stuart (cc'ed) about 6 months > ago about this, but gave up because I couldn't manage to compile > everything with the debugging symbols. This time after much struggle to > compile the ports chain with them, I finally managed to run > milter-greylist in gdb(1) with the hope to witness the live crash and > get a detailed stacktrace... > > Except that even after tinkling Postfix, it never happened. This simply > worked fine. So after some more tinkering I came to the following > conclusion: if I run strip(1) on /usr/local/lib/libbind/libbind.so.5.0 > to remove the debugging symbols, then it will crash with the stacktrace > below. > > Has anyone of you seen such a behavior in the past? > > #0 0x00001cc53e386d40 in memcpy (dst0=0x1cc5c48b7000, src0=Variable "src0" is not available. Do you have any idea why "src0" isn't available here? That might be a good place to start. > ) at /usr/src/lib/libc/string/memcpy.c:94 > #1 0x00001cc4f4d496d8 in __res_vinit () from /usr/local/lib/libbind/libbind.so.5.0 > #2 0x00001cc4f4d48bda in __res_ninit () from /usr/local/lib/libbind/libbind.so.5.0 > #3 0x00001cc50b181905 in SPF_dns_resolv_lookup (spf_dns_server=0x1cc5c48ab780, domain=0x1cc55122c1d0 "mydomain.org", rr_type=ns_t_spf, should_cache=1) at spf_dns_resolv.c:261 > #4 0x00001cc50b180117 in SPF_dns_lookup (spf_dns_server=0x1cc5c48ab780, domain=0x1cc55122c1d0 "mydomain.org", rr_type=ns_t_spf, should_cache=1) at spf_dns.c:141 > #5 0x00001cc50b180b16 in SPF_dns_cache_lookup (spf_dns_server=0x1cc5c48abc80, domain=0x1cc55122c1d0 "mydomain.org", rr_type=ns_t_spf, should_cache=1) at spf_dns_cache.c:408 > #6 0x00001cc50b180117 in SPF_dns_lookup (spf_dns_server=0x1cc5c48abc80, domain=0x1cc55122c1d0 "mydomain.org", rr_type=ns_t_spf, should_cache=1) at spf_dns.c:141 > #7 0x00001cc50b18e4e3 in SPF_server_get_record (spf_server=0x1cc5eb4154c0, spf_request=0x1cc5c48aeb00, spf_response=0x1cc5eb41b400, spf_recordp=0x1cc54f7c8700) at spf_server.c:351 > #8 0x00001cc50b18c959 in SPF_request_query_mailfrom (spf_request=0x1cc5c48aeb00, spf_responsep=0x1cc54f7c87a0) at spf_request.c:291 > #9 0x00001cc2ee1207ca in spf_check_internal (ad=0x1cc4f4c65948, as=AS_RCPT, ap=0x1cc54f7c8cd0, priv=0x1cc5c48af000) at spf.c:388 > #10 0x00001cc2ee120c17 in spf_check (ad=0x1cc4f4c65948, as=AS_RCPT, ap=0x1cc54f7c8cd0, priv=0x1cc5c48af000) at spf.c:524 > #11 0x00001cc2ee123a0d in acl_filter (stage=AS_RCPT, ctx=0x1cc5c48b2000, priv=0x1cc5c48af000) at acl.c:1902 > #12 0x00001cc2ee1069ae in real_envrcpt (ctx=0x1cc5c48b2000, envrcpt=0x1cc5eb41c280) at milter-greylist.c:601 > #13 0x00001cc2ee105de0 in mlfi_envrcpt (ctx=0x1cc5c48b2000, envrcpt=0x1cc5eb41c280) at milter-greylist.c:213 > #14 0x00001cc52bfaa46e in st_rcpt () from /usr/local/lib/libmilter.so.4.0 > #15 0x00001cc52bfab557 in mi_engine () from /usr/local/lib/libmilter.so.4.0 > #16 0x00001cc52bfaca10 in mi_handle_session () from /usr/local/lib/libmilter.so.4.0 > #17 0x00001cc52bfab7d9 in mi_thread_handle_wrapper () from /usr/local/lib/libmilter.so.4.0 > #18 0x00001cc5a247d90e in _rthread_start (v=Variable "v" is not available. > ) at /usr/src/lib/librthread/rthread.c:145 > #19 0x00001cc53e33649b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 > #20 0x0000000000000000 in ?? () > > > -- > Jeremie Le Hen > j...@freebsd.org > -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html
