Re: c4gl core dumps: (script calls 'i4glc1' which seems to be 'i4gl' and 'i4gl' is core dumping)

[snip] > Diagnosis and observations so far: > > 1) I get a *.err file before the segmentation fault, and this file is > truncated. About half of the file is there, but it is truncated in the > middle of a function. > 2) It always seems to truncated the file at the same point, so I figured I > would try breaking the file out into two files. I did this, keeping the > "first half" of the new file shorter than the point where the file was > truncated. That works - this new "first half" of the file compiles. > However, the new "second half" causes a segmentation fault, even if there is > no functions in the file. Only a "database XXXX" and a "globals XXXX" line > in the file. (No MAIN, and no FUNCTIONs are even in the "second half" file, > and segmentation fault occurs.) > 3) In the Makefile file, I already tried the use of 'STACKFLAGS = -S 65536' > which was formerly set to 32768. This did not change where, or what file, > the segmentation fault occurs. > 4) Using a "binary search elimination" of source code stategy, I figured out what "triggers" this infamous seg fault. Look at the difference between these two SELECTs: a) This SELECT causes a seg fault when compiled into my 4GL program code: SELECT iv_f.*, od_f.*, om_f.* INTO rec_ivf.*, rec_odf.*, rec_omf.* <-- Too large, some kind of STACK limit reached? Get SEG FAULT compiling with c4gl. FROM iv_f, od_f, om_f WHERE (iv_f.iv_rid = rec_rid) AND (iv_f.ob_oid = od_f.ob_oid) AND (iv_f.ob_type = od_f.ob_type) AND (iv_f.ob_lno = od_f.ob_lno) AND (iv_f.ob_oid = om_f.ob_oid) AND (iv_f.ob_type = om_f.ob_type) b) When I comment out the INTO "clause" the 4GL program compiles without any seg fault: SELECT iv_f.*, od_f.*, om_f.* FROM iv_f, od_f, om_f WHERE (iv_f.iv_rid = rec_rid) AND (iv_f.ob_oid = od_f.ob_oid) AND (iv_f.ob_type = od_f.ob_type) AND (iv_f.ob_lno = od_f.ob_lno) AND (iv_f.ob_oid = om_f.ob_oid) AND (iv_f.ob_type = om_f.ob_type) One triggers a seg fault, and the other does not. Now, all three of the records are defined in the "viaware" database, are all are owned by the currently logged in user. This really is starting to look like some sort of software limitation of the 4GL compiler. Possibly a program stack limit that is reached when all of the fields from all 3 of these tables, om_f, iv_f, and od_f are compiled for all three of the records? Does this provide anyone looking at this with some clues? Again, I have the STACKFLAGS at 65536 already, I am going to increase this to a ridiculously high value to see if it happens to be the right "limit" env var to bump up... but I'm skeptical. [snip] > > > -Darrin > darrin.wolf at provia dot com > > Please just reply to the newsgroup--share the knowledge--thanks! > > > >