hb@pixar.UUCP (H. B. Siegel) (12/01/89)
Machine: NeXT running 0.990 (almost 1.0) Version: Gawk 2.11.1 (patchlevel 1, applied from gnu.utils.bug #608) Special Makefile compilation flags: MISSING = -DSTRERROR_MISSING -DSTRCASE_MISSING -DBSDSTDIO -bsd I'm hitting a bug that causes a segmentation fault on this line: Program received signal 11, Segmentation fault: 0xdb00 in assoc_next (lookat=(struct search*) 0x4bf10) (array.c line 261) 261 lookat->bucket = *++(lookat->arr_ptr); It is buried within about 12 levels of r_tree_eval(),interpret(), and func_call(). I've written my own version of a debugging malloc, which doesn't cause gawk to fault. The NeXT system one does, although this is not a definite implication of problem with NeXT's malloc (since they alloc differently, gawk could be trashing an "unimportant" area with my malloc). The bug is deterministic. The awk file that creates the problem is quite large: about 745 lines. It's a recursive descent parser modelled after the one in The Awk Programming Language (Aho, etal). The input file is about 50 lines. Either trimming the input file or the awk file will cause the problem to go away, so I can't use the standard debugging methodology of trimming away correct code. Granted, there is clearly not enough for anyone else to debug with here, but before I devote any more time (2 full days already), I would like to know if someone else ran across this one, (and fixed it :-) ) ? H.B.