On Wed, Nov 27, 2019 at 03:30:23PM +0100, Peter J. Philipp wrote: > Hi David, > > I'm going to upgrade to -current and then report back.. it'll take me a few > days to do that (I'm super slow). > > ... > I'll see if this sort of issue repeats after I upgrade the octeon router > to -current. > > Thanks! > -peter
Hi David and Misc@, OK this is weird. For people who are just reading this thread it's about OpenBSD/octeon SIGBUS'ing my program with an unalignment error. I upgraded to -current (very pleased that pppoe0 works now, as an aside), and got the debug right after the fork. Here is the output of gdb debug.1---> Continuing. Program received signal SIGBUS, Bus error. lookup_axfr (f=0x2c6274db78, so=6, zonename=0x2c6b3d2130 "words.", mysoa=0xfffffe7920, format=20, tsigkey=0x2c37b083d0 "pass", tsigpass=0xfffffe7b60 "*censored*=", segment=0xfffffe7b40, answers=0xfffffe7b3c, additionalcount=0xfffffe7b38) at util.c:1842 1842 *type = htons(DNS_TYPE_AXFR); (gdb) list 1837 1838 memcpy(p, name, len); 1839 totallen += len; 1840 1841 type = (u_int16_t *)&query[totallen]; 1842 *type = htons(DNS_TYPE_AXFR); 1843 totallen += sizeof(u_int16_t); 1844 1845 class = (u_int16_t *)&query[totallen]; 1846 *class = htons(DNS_CLASS_IN); (gdb) print type $1 = (u_int16_t *) 0xfffffe763d <----- So I point a pointer of type u_int16_t to a memory address (which may be unaligned) and then load it with a value. I've always done it this way throughout my program, but just to be sure that it isn't caused by the stack somehow I moved query variable to the heap (or it's equivalent) and tried again. debug.2---> Loaded symbols for /usr/libexec/ld.so pull_remote_zone (lrz=0x216549d000) at parse.y:3605 3605 while (debugger == 1) (gdb) set debugger=0 Current language: auto; currently minimal (gdb) cont Continuing. Program received signal SIGBUS, Bus error. lookup_axfr (f=0x21b8dfdb78, so=6, zonename=0x22041a4a10 "words.", mysoa=0xffffff9050, format=20, tsigkey=0x22052c35b0 "pass", tsigpass=0xffffff9290 "*censored*=", segment=0xffffff9270, answers=0xffffff926c, additionalcount=0xffffff9268) at util.c:1849 1849 *type = htons(DNS_TYPE_AXFR); (gdb) print type $1 = (u_int16_t *) 0x21d57f1015 (gdb) print query $2 = 0x21d57f1000 "" (gdb) print (char*)type - query $3 = 21 <------- So now I have a true offset of variable type it's not aligned. What can I do here? Does this need fixing in OpenBSD/octeon or do I have to fix my code for this? I don't really know what to use instead of this other than memcpy'ing this value instead of (overloading?) the 16 bit integer. Any help is welcomed! Best regards, -peter