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. [...] -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
