Re: 4GL Core Dumps. Help!

Path: emory!gatech!ukma!rutgers!pyrnj!pyramid!infmx!aland From: aland@informix.com (Colonel Panic) Newsgroups: comp.databases.informix Message-ID: <1991Sep25.023838.24446@informix.com> Date: 25 Sep 91 02:38:38 GMT References: <1991Sep24.045337.22349@informix.com> <1991Sep24.115156.1319@cbfsb.att.com> Sender: news@informix.com (Usenet News) Organization: International Brotherhood of Geeks, Local 619 In article <1991Sep24.115156.1319@cbfsb.att.com> nll@cbnewsb.cb.att.com (neal.l.leitner) writes: >From article <1991Sep24.045337.22349@informix.com>, by aland@informix.com (Colonel Panic): >Nope, he is not lying. I recompiled everything again using the -lmalloc >library and it has not core dumped yet. But unfortunately it doesn't >explain why it would work some of the time and not all the time. In addition, Indeed. This is why I fail to understand why you attribute those symptoms (where once the program failed once, it would continue to fail regularly until recompiled) to 4GL rather than to the hardware or O/S. Once 4GL has produced an executable, if the executable itself changes, it's not 4GL's fault. If you get failures intermittently, depending on data and/or sequence of events when running the program, that's another story; it may be 4GL, it may be programmer error, it may be the O/S, or it could even be hardware. >we have another programmer here who is using 4GL as well and is also getting >Core Dumps (The Tech. is working with him). I thought 4GL was supposed to >be able to elimiate things like Core Dumps?? You'll never "eliminate" core dumps any more than you'll ever produce a completely bug-free product. Another complicating factor is that some environments are more picky about memory than others; some will let you get away with misbehaving, some won't. For example, the known bug I mentioned in the last mail (last field of a CONSTRUCT) shows up on some environments but not others, but it's still a wrong thing to do and has been fixed generically. Core dump bugs get the highest fix priority aside from bugs that corrupt data or produce wrong results, since they generally leave minimal context that will help find the point of failure to someone unfamiliar with C and debuggers. >By the way, what is the latest >release (part number as well) of Informix for the AT&T 6386/33E running >Unix 3.2.3?? As I mentioned in the last mail, the latest for the 6386 was ported to SVR3.2.2, but I know of no problems running on 3.2.3. The version is 4.00.UD3. It's basically the original UD2 plus the aforementioned CONSTRUCT fix. The parent port #s are 001072 (3.5") and 001073 (5.25"). There's no newer version as yet, though a 4.00.UJ2 and 4.10.UC? are scheduled. If you need more detail, email. I've tried the 4.00.UH2 SCO UNIX port on AT&T and it definitely does NOT work because SCO's changes to rcc result in undefineds when using those libraries on AT&T. >Neal Leitner >...att!emdbl1!nll -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland "In the cafeteria just after lunch, (well, not *just* after, more like *during* lunch, about 12:28; say 12:30, give or take a few minutes), I leaned back in my chair (it was one of those aluminum chairs, good strength-to-weight, like titanium but not quite; but then of course titanium would be a bit of an overkill). Anyway, I heard one of the girls talking about how boring she thought engineers could be."