Re: Part II: Revenge of the CoreDumps

Carlson@WHSmith wrote: > > SaTriGuy wrote: > > > > If the program is a compiled program, and is producing a core file, then you > > can start by getting the stack trace from the core file. This can be done by > > using xdb and/or adb. This should help in the resolution of the problem. > > > > What is the case number?? > > #789609 > > How do I need to compile a 4gl in order to use a debugger? I know that > I can't STRIP the executable, as I do now. > > BTW, a clean run today at 10:30 in cron. I reset the cron to take place > at 6:30AM tomorrow, just to see what happens. > Ran it this week (6:30AM); it ran fine for Saturday and Monday, errored out. OK, I adjusted the source code to the point where I was getting predictable coredumps and recompiled (keeping the .ec file). I ran the executable and got a core file in return. I attempted to start xdb with the executable name and core file, and it can't read the core file. Here's the error: <<<< XDB Version A.10.00 HP-UX >>>> Do you want to save a backup copy of the core file? y Core file saved as "core23303" Registers bad in core file (UE644) Error trying to read "core"; ignoring it (UE646) Procedures: 17 Files: 1 No problem, I execute the program from within xdb with the appropriate arguments; that's where the source code map is pointing me. It loads the shared memory maps and executes the program. Here's what pops up next: >r -h 90 -i N Starting process 23646: "db_rpt.4ge -h 90 -i N" Wait...loading shared-library map tables. Done. segmentation violation (no ignore) at 0xc009ccf0 (file unknown): TMEM@libc.1 +0x00088cf0: (line unknown) What now? I've been around 4gl for a little while (4 1/2 years) but this is stretching me just a bit. TIA John Carlson Informix DBA WHSmith USA