Re: cfglgo problem on Linux

On Tuesday 5th October 1999, "Cecilio Albero" <eos@ctv.es> wrote: >This is the stack trace of gdb myfgldb: > >#0 0x80980c5 in _addstr () >(gdb) #0 0x80980c5 in _addstr () >#1 0x8098086 in addgstr () >#2 0x80975e1 in addfunc () >#3 0x809762f in addcf () >#4 0x80976e1 in addcfuncs () >#5 0x809b9a9 in loadone () >#6 0x809b892 in loadfile () >#7 0x809c067 in loadprog >#8 0x8086f66 in initload () >#9 0x807c30d in main () > >and this the stupid 4gl: > >main > define k smallint > let k=1 > display k >end main > >> Can you generate a stack trace from the core dump? >> >> gdb myfgldb core <<! >> where >> quit >> ! >> >> If it shows up as a core dump in fgl_init(), then go back to the >> edits in cfgldb and check that you've done it right. If it shows >> up somewhere else, post it. Hmmm. Now we're into that horrible area of "I cannot reproduce the problem". I used the plain custom debugger (cfgldb -o myfgldb $INFORMIXDIR/etc/fgiusr.c) and it core dumped in iosetbuffer (under fgl_init) as I'd expect. But, when I changed the compiler to use i386-glibc20-linux-gcc, the debugger loaded your sample program (from a file stupid.4go compiled from stupid.4gl), and ran it OK -- no core dump. My testing is on a plain RedHat 6.0 installation, kernel 2.2.5-15smp, glibc 2.1.1, no patches to kernel. I'm not sure what to suggest from here. If you have support, take it to Informix Tech Support. But that's the easy bit and you probably would not be asking if you had support. Yours, Jonathan Leffler (jleffler@informix.com) #include <disclaimer.h> Guardian of DBD::Informix v0.62 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"