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 "@:defseqsc...@[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® 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/monetdb-developers
--
Sjoerd Mullender
------------------------------------------------------------------------------
Download Intel® 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers
