After a quick look at the code, perhaps the problem is that the string that is being worked on starts with a MARK ('@') and so the test is wrong. Can you change the two occurrences near line 503 of if (s[0] == MARK && s[-1] != '\' ... to if (s[0] == MARK && s > sub && s[-1] != '\' ... and see whether the crash still occurs?

On 2010-03-01 01:43, Mark Bucciarelli wrote:

Hi,

I'm getting a segfault when running Mx, in buildtools/Mx/Code.c, CodeSubBlk().

The symptom is around line 305---s[-1] is not accessible memory.

Any suggestions for how to debug/fix this?

I got as far as looking at def in the parent frame (CodeSub()):

(gdb) print *def $9 = { d_dir = Mxmacro, d_cmd = 0x8592e110 "DEFseqscan", d_blk = 0x89ca2000 "@:DEFseqscan_@[10](@1,@2,@3,@4,@5,@6,@7,@8,@9)@\n", d_mod = 0, d_sec = 0, d_cms = 0xd0d0d0d0 <Address 0xd0d0d0d0 out of bounds>, d_file = 0x86c3a080 "gdk_scanselect_defs.mx", d_line = 132 } (gdb)

This is the Feb2010 branch, on OpenBSD 4.6 with the following malloc.conf options:

 A       ``Abort''.  malloc() will coredump the process, rather than tol-
         erate internal inconsistencies or incorrect usage.  This is the
         default and a very handy debugging aid, since the core file rep-
         resents the time of failure, rather than when the bogus pointer
         was used.
 G       ``Guard''.  Enable guard pages.  Each page size or larger alloca-
         tion is followed by a guard page that will cause a segmentation
         fault upon any access.
 J       ``Junk''.  Fill some junk into the area allocated.  Currently
         junk is bytes of 0xd0 when allocating; this is pronounced
         ``Duh''.  :-) Freed chunks are filled with 0xdf.
 P       ``Move allocations within a page.'' Allocations larger than half
         a page but smaller than a page are aligned to the end of a page
         to catch buffer overruns in more cases.  This is the default.

I was getting these when building Nov2009, but I was able to get past them by restarting the build multiple times.

I'd like to fix it this time around. Fortunately, after a gmake clean the crash is reproduceable.

Thanks,

m

---

Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers