On Sun, 2011-05-15 at 23:34 +0200, Samuel Thibault wrote: > Svante Signell, le Sun 15 May 2011 23:20:52 +0200, a écrit : > > Segmentation fault > > Do you have a core file? Does your shell perhaps has limited core size > limit? (ulimit -a to check)
Sorry I don't find any core file anywhere: ulimit -a socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited > > srs@kvm-hurd:~/DEBs/exim/exim4-4.76$ > > > > And with gdb the only output I get is (and no stack) > > gdb build-tree/build-exim4-daemon-light/exim > > > > Cannot access memory at address 0xffff548d > > > > (I get this by just requesting: run from the gdb prompt, no file needed) > > > > gdb bug? > > The address is really bogus, use show registers to know where it comes > from, check eip, say 0x1234, use l * 0x1234 to know where that is, etc., > i.e. the usual "let's collect all trivial information before looking for > some direction". Sorry, I need more info here. I've completely (intentionally) forgotten assembly (the DOS/i386 assembly reference manual was thrown into the garbage many years ago, I did not expect to have to ever use it again). I thought development was made with high-level languages nowadays (at least C-level) Update on optimization levels: -O1 does not work either :( Other compiler switches are: -fno-strict-aliasing -fvisibility=hidden -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wall There are a lot of warnings though: maybe some of them can cause problems. Not all looks trivial.
