Hey thanks a million! I looked on your homepage and didn't find any paypal address listed so I'm going to donate in your name to Theo. I think when you two meet Theo should buy you a beer with part of the money. :-), or any other beverage in case you don't like beer.
Thanks again! Donation sent. -peter On 08/08/17 01:36, Jeremie Courreges-Anglas wrote: > On Mon, Aug 07 2017, "Peter J. Philipp" <p...@centroid.eu> wrote: >> Hi, > Hi, > >> I'm writing to misc because I did a change with my programming project and >> it doesn't work, in fact the program does not start up but in the dynamic >> linking stage (it seems) cores on segmentation violation. I have tried >> different architectures (amd64 and octeon) and -current and both have the >> same problem, but I develop mostly on 6.1. When I run it through a debugger >> I get this: >> >> (gdb) run >> Starting program: /usr/local/sbin/delphinusdnsd >> (no debugging symbols found) >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x000018c933300c94 in ?? () from /usr/local/sbin/delphinusdnsd >> (gdb) bt >> #0 0x000018c933300c94 in ?? () from /usr/local/sbin/delphinusdnsd >> #1 0x000018c933300b3e in ?? () from /usr/local/sbin/delphinusdnsd >> #2 0x0000000000000000 in ?? () >> >> Apparently somewhere in the program something jumps to location 0 and from >> there it's downhill. >> >> Also the very first system call (a geteuid()) does not get called making me >> think it's before main() has been called. I'm completely boggled by this. >> >> # kdump | grep -3 geteuid >> # >> >> The last committed snapshot of my program is found here, and afaik it works: >> >> http://delphinusdns.org/delphinusdnsd-snapshot.tgz >> >> The changes I'm working on now which causes this weird behaviour is to tie in >> imsg into my program and that means linking -lutil with this program. I've >> checked if there was any macro collisions with TAILQ's or RB_HEAD's and >> tried >> to move those out of the way but still I get the segmentation fault. >> >> If anyone has an idea as to what could be the cause of this I'd be grateful. > Your program blows up the stack right at the start of main(), and gdb > doesn't seem to handle this very nicely. egdb from ports shows you > the faulty instruction in the listing of ''disas main'', gdb from base > doesn't seem to do that (but you can still find it out manually). > > Increasing the max stack size with ulimit -s, reducing the size of the > parent_ibuf and child_ibuf arrays, or allocating them in a different way > would work around those issues. > > [...] >
