Core dump: ixpshhwm Solaris7 64bit

Hej! We have some problems with Informix 4gl 7.30.FC4 on a Sun Enterprise 450. >uname -a SunOS 5.7 Generic_106541-06 sun4u sparc SUNW,Ultra-4 >isainfo -v 64-bit sparcv9 applications 32-bit sparc applications If i compile a small program with c4gl, the resulting a.out produces a "Segmentation fault". test.4gl: MAIN DISPLAY "Hallo Welt" EXIT PROGRAM END >adb a.out Ignoring unrecognized note segment entry 8. core file = core -- program ``a.out'' on platform SUNW,Ultra-4 SIGSEGV: Segmentation Fault $c strlen(1,100,ffffffff7fffe910,100000fe0,0,ffffffff7fffe910) + 1c ixpshhwm(ffffffff7f636f64,1,ffffffff7f618430,10010d900,0,0) + 114 main(1,ffffffff7fffeac8,ffffffff7fffead8,ffffffff7e6aeb40,0,100000000) + 40 The line with ixpshhwm in the resulting c-File is: ixpshhwm((char *)0); Is this a char-pointer to the address 0 (Pointer to NULL)? Checks ixpshhwm perhaps the length of this parameter? Does anybody know anything about the bug11302, which can be found in $INFORMIXDIR/incl/tools/fglsys.h ? >grep ixp * fglsys.h:extern void ixpophwm(void); fglsys.h:extern void ixpshhwm(char *); /* bug11302 */ fglsys.h:extern void ixpophwm(); fglsys.h:extern void ixpshhwm(); > Last but not least: Any help? Thank you! Thomas Behr (the guy with the atypical inns in northern bavaria ;-) ---- ___ | \\ \\ | | UNIVERSITY OF | Dipl.-Ing. agr. Thomas Behr \\ \\ | | BAYREUTH | Thomas.Behr@uvw.uni-bayreuth.de \\ \\| | | voice: (++49) 921 - 55 52 75 \\_______| DEZERNAT Z/DV | fax: (++49) 921 - 55 84 52 75 | Postfach 101251 D95440 Bayreuth Sent via Deja.com http://www.deja.com/

Thomas Behr wrote: > > Hej! > We have some problems with Informix 4gl 7.30.FC4 on a > Sun Enterprise 450. > > >uname -a > SunOS 5.7 Generic_106541-06 sun4u sparc SUNW,Ultra-4 > >isainfo -v > 64-bit sparcv9 applications > 32-bit sparc applications > > If i compile a small program with c4gl, the resulting a.out produces a > "Segmentation fault". > > test.4gl: > MAIN > DISPLAY "Hallo Welt" > EXIT PROGRAM > END > > >adb a.out > Ignoring unrecognized note segment entry 8. > core file = core -- program ``a.out'' on platform SUNW,Ultra-4 > SIGSEGV: Segmentation Fault > $c > strlen(1,100,ffffffff7fffe910,100000fe0,0,ffffffff7fffe910) + 1c > ixpshhwm(ffffffff7f636f64,1,ffffffff7f618430,10010d900,0,0) + 114 > main(1,ffffffff7fffeac8,ffffffff7fffead8,ffffffff7e6aeb40,0,100000000) + > 40 > > The line with ixpshhwm in the resulting c-File is: > ixpshhwm((char *)0); > > Is this a char-pointer to the address 0 (Pointer to NULL)? > Checks ixpshhwm perhaps the length of this parameter? > Does anybody know anything about the bug11302, which can be found in > $INFORMIXDIR/incl/tools/fglsys.h ? > >grep ixp * > fglsys.h:extern void ixpophwm(void); > fglsys.h:extern void ixpshhwm(char *); /* bug11302 */ > fglsys.h:extern void ixpophwm(); > fglsys.h:extern void ixpshhwm(); > > > > Last but not least: Any help? I wrote the original code using ixpshhwm() et al. It gets rid of the dire but long forgotten problems with running out of temporary string space (error -4518). The original bug was 1857. Now, in the code as I left it (back in 1995 or thereabouts), ixpshhwm() did not take any argument. However, I find a reference to bug 111302 in the source code, and ixpshhwm() now takes a 'char *' argument. This provides the file name (the function name could be provided instead, or as well; either or both were seen as possible extensions when I wrote the original version). Did you really recompile all your I4GL source code? Did you ever write any C code that calls ixpshhwm()? If you really did recompile everything and you still have problems, then we'll need to look at the .c file for your program and see whether ixpshhwm provides a value or not. The code I see does check whether the string passed is a null pointer before doing anything with it, and it does not do strlen() directly on it -- it uses strdup() which does strlen(). Unless there's a macro implementing strdup as strcpy(malloc(strlen(s)),s) or something equally dire. There are numerous possible sources of the trouble. Either the incorrect compiler options are in use (so something is being compiled 32-bit when it should be 64-bit), or the wrong version of the shared libraries are in use, or ... However, your trivial example suggests the problem is with the I4GL product and not with your code per se. Are you using the correct (version 5) SUNWspro C compiler? GCC won't work reliably for 64-bit Solaris -- well, I never got it anywhere near compiling, but I'd be delighted to be told I'm wrong on that. Aside: Bug 11302 was related to ESQL/C and DOS -- I fail to see how it can be relevant to this: ESQL/C DOES NOT PROCESS 2 .EC FILE, PROCESS ONLY 1 .EC FILE. In fact, as explained above, the relevant bug is 111302, and there is therefore an extra bug in the code as a result of the comment being erroneous! -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

In article <3A6DD52B.848BA057@informix.com>, Jonathan Leffler <jleffler@informix.com> wrote: > I wrote the original code using ixpshhwm() et al. It gets rid of the I know and i hoped, that you answer ;-) > Did you really recompile all your I4GL source code? yes > Did you ever write > any C code that calls ixpshhwm()? no > If you really did recompile > everything and you still have problems, then we'll need to look at the > .c file for your program and see whether ixpshhwm provides a value or > not. from test.c: main(fgl_argc, fgl_argv) int fgl_argc; char *fgl_argv[]; { fgl_init(fgl_argc, fgl_argv); fgl_siginit(); ixpshhwm((char *)0); _anyerr = 1; /* * $ display "Hallo Welt"; */ { { static struct sqlvar_struct _sqibind[] = { {109, 0}, }; _sqibind[0].sqldata =("Hallo Welt"); _eflndsply(1, _sqibind, 1); } } status = efcode; if (status < 0) { fgl_fatal(fgl_modname, 3, status); } _autofree(0); /* * $ exit form mode; */ { _efemode(); } ixrelhwm(); exit(0); > Either the incorrect compiler options are in use (so something is being > compiled 32-bit when it should be 64-bit), or the wrong version of the > shared libraries are in use, or ... Hm, does anybody know the correct settings for all the environment (LD_LIBRARY_PATH,LD_LIBRARY_PATH_64, LD_RUN_PATH, LD_OPTIONS ...) and options? Which cc ist the correct one (/usr/ucb/cc or /usr/ccs/bin/ucbcc [=> order of the libraries])? > However, your trivial example suggests the problem is with the I4GL > product and not with your code per se. Are you using the correct > (version 5) SUNWspro C compiler? yes: WorkShop Compilers 5.0 98/12/15 C 5.0 > GCC won't work reliably for 64-bit Solaris -- well, I never got it I know that gcc works only on 32-bit Solaris (-f writeable_strings). mfg thomas -- ---- ___ | \\ \\ | | UNIVERSITY OF | Dipl.-Ing. agr. Thomas Behr \\ \\ | | BAYREUTH | Thomas.Behr@uvw.uni-bayreuth.de \\ \\| | | voice: (++49) 921 - 55 52 75 \\_______| DEZERNAT Z/DV | fax: (++49) 921 - 55 84 52 75 | Postfach 101251 D95440 Bayreuth Sent via Deja.com http://www.deja.com/

In article <3A6DD52B.848BA057@informix.com>, Jonathan Leffler <jleffler@informix.com> wrote: > Thomas Behr wrote: ... > > The line with ixpshhwm in the resulting c-File is: > > ixpshhwm((char *)0); ... > FILE. In fact, as explained above, the relevant bug is 111302, and > there is therefore an extra bug in the code as a result of the comment > being erroneous! The bug 111302 is the important hint Releasenote TOOLREL_7.30: > III. NOTE FOR FIX OF BUG#111302: > -------------------------- > A new environment variable NEWERRLOG is introduced. If this variable > is set,error log will include module name and line number else the > behaviour will be as it used to be.Note,the environment variable needs > to be set during compile time.Setting it during run time will have no > effect. If i set this variable NEWERRLOG, the line of ixpsshwm is: ixpshhwm(fgl_modname); And now my little program runs! The precompiler (from *.4gl to *.4ec) produces different code, if NEWERRLOG is set; or it produces buggy code, if NEWERRLOG is not set. Now i will verify this on our large Project (about 1000 different 4gl's). Thank you very much! Thomas Sent via Deja.com http://www.deja.com/