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

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

Post by Darrin Wol » Thu, 26 Jun 2003 00:00:52



Hi guys,

I'm affraid that I have run into another unsolvable porting problem today.
We have a 4GL file in one of our libraries that, when built via the 'c4gl'
INFORMIX script, causes a segmentation fault.

Here is what it looks like during the build:

And here is what 'dbx' is giving me for information:

# dbx ./i4glc1 ./core
Type 'help' for help.
[using memory image in ./core]
reading symbolic information ...warning: no source compiled with -g

Segmentation fault in effldflg_newICBEntry at 0x100024240 ($t1)
0x100024240 (effldflg_newICBEntry+0xd0) 4082000c        bne   0x10002424c
(effldflg_newICBEntry+0xdc)
(dbx) where
effldflg_newICBEntry() at 0x100024240
ix_extract() at 0x100023bb8
ix_mkprefix() at 0x10000fe00
ix_incfile() at 0x1000032d0

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.

Has anyone seen anything like this before?  I have been snooping around in
the 'c4gl' script for shell parameters that I might be able to hack with,
but there are quite a few.  Any information on which ones I might be related
to limitations, and which ones are my best bet for getting past this
problem?

================================= Version Information
==================================
# c4gl -V
IBM INFORMIX-4GL Version   7.32.FC1
Software Serial Number RDS#N[XXXXXX]

# i4gl -V
IBM INFORMIX-4GL Version   7.32.FC1
Software Serial Number RDS#N[XXXXXX]

# chkenv
Checking shared environment configuration file: /informix/etc/informix.rc
Checking private environment configuration file: /home/djw/.informix

# chkengine
on

# chkserver
on

# uname -va
AIX finch 2 5 000AB86D4C00

# xlC_r
VisualAge C++ Professional / C for AIX Compiler, Version 6

# onstat -V
Informix Dynamic Server Version 7.31.FD6     Software Serial Number
ACP#J[XXXXXX]

# onstat -p

Informix Dynamic Server Version 7.31.FD6     -- On-Line -- Up 5 days
22:43:36 -- 36752 Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
2391     3442     7434936  99.97   6044     9801     205175   97.05

isamtot  open     start    read     write    rewrite  delete   commit
rollbk
4734910  88990    398907   3116655  36281    659      493      11406    0

gp_read  gp_write gp_rewrt gp_del   gp_alloc gp_free  gp_curs
0        0        0        0        0        0        0

ovlock   ovuserthread ovbuff   usercpu  syscpu   numckpts flushes
0        0            0        247.72   155.96   8        3428

bufwaits lokwaits lockreqs deadlks  dltouts  ckpwaits compress seqscans
557      0        6124529  0        0        3        120      11203

ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
196      0        196      392        17

-Darrin
darrin.wolf  at provia  dot com

Please just reply to the newsgroup--share the knowledge--thanks!

 
 
 

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

Post by Darrin Wol » Thu, 26 Jun 2003 00:11:29



Quote:> Hi guys,

> I'm affraid that I have run into another unsolvable porting problem today.
> We have a 4GL file in one of our libraries that, when built via the 'c4gl'
> INFORMIX script, causes a segmentation fault.

> Here is what it looks like during the build:

Sorry, I missed the 'paste' here typical when I have too many interuptions
and meetings to attend :-0
--------------------------------------

[snip - many files built by c4gl successfully...]

c4gl -s -DAIX -I/testinf/viaware/wms/4glrfclient/h -I/informix//incl -I/info
rmix//incl/tools  -I/testinf/viaware/wms/4glrfclient/glo
bals  -c cpordcan.4gl
rm -f cpordcan.ec
rm -f cpordcan.c
ar -r -v -X64 /testinf/viaware/lib/cmplib.a cpordcan.o
r - cpordcan.o
rm -f cpordcan.o
ls  /testinf/viaware/lib/cmplib.a
/testinf/viaware/lib/cmplib.a
c4gl -s -DAIX -I/testinf/viaware/wms/4glrfclient/h -I/informix//incl -I/info
rmix//incl/tools  -I/testinf/viaware/wms/4glrfclient/glo
bals  -c cpcntman.4gl
rm -f cpcntman.ec
rm -f cpcntman.c
ar -r -v -X64 /testinf/viaware/lib/cmplib.a cpcntman.o
r - cpcntman.o
rm -f cpcntman.o
ls  /testinf/viaware/lib/cmplib.a
/testinf/viaware/lib/cmplib.a
c4gl -s -DAIX -I/testinf/viaware/wms/4glrfclient/h -I/informix//incl -I/info
rmix//incl/tools  -I/testinf/viaware/wms/4glrfclient/glo
bals  -c cputilfn.4gl
rm -f cputilfn.ec
rm -f cputilfn.c
ar -r -v -X64 /testinf/viaware/lib/cmplib.a cputilfn.o
r - cputilfn.o
rm -f cputilfn.o
ls  /testinf/viaware/lib/cmplib.a
/testinf/viaware/lib/cmplib.a
c4gl -s -DAIX -I/testinf/viaware/wms/4glrfclient/h -I/informix//incl -I/info
rmix//incl/tools  -I/testinf/viaware/wms/4glrfclient/glo
bals  -c cpbchrecfly.4gl
/informix/bin/c4gl[283]: 331808 Segmentation fault(coredump)
gmake: *** [/testinf/viaware/lib/cmplib.a(cpbchrecfly.o)] Error 139
finch /testinf/viaware/wms/4glrfclient/cmp

--------------------------------------

NOTE:  The 'ls' that appears after every 'rm' is the new $(RANLIB) make
rule.  It used to be 'ranlib' which I am told is no longer necessary.

Quote:> And here is what 'dbx' is giving me for information:

> # dbx ./i4glc1 ./core
> Type 'help' for help.
> [using memory image in ./core]
> reading symbolic information ...warning: no source compiled with -g

> Segmentation fault in effldflg_newICBEntry at 0x100024240 ($t1)
> 0x100024240 (effldflg_newICBEntry+0xd0) 4082000c        bne   0x10002424c
> (effldflg_newICBEntry+0xdc)
> (dbx) where
> effldflg_newICBEntry() at 0x100024240
> ix_extract() at 0x100023bb8
> ix_mkprefix() at 0x10000fe00
> ix_incfile() at 0x1000032d0

> 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.

> Has anyone seen anything like this before?  I have been snooping around in
> the 'c4gl' script for shell parameters that I might be able to hack with,
> but there are quite a few.  Any information on which ones I might be
related
> to limitations, and which ones are my best bet for getting past this
> problem?

> ================================= Version Information
> ==================================
> # c4gl -V
> IBM INFORMIX-4GL Version   7.32.FC1
> Software Serial Number RDS#N[XXXXXX]

> # i4gl -V
> IBM INFORMIX-4GL Version   7.32.FC1
> Software Serial Number RDS#N[XXXXXX]

> # chkenv
> Checking shared environment configuration file: /informix/etc/informix.rc
> Checking private environment configuration file: /home/djw/.informix

> # chkengine
> on

> # chkserver
> on

> # uname -va
> AIX finch 2 5 000AB86D4C00

> # xlC_r
> VisualAge C++ Professional / C for AIX Compiler, Version 6

> # onstat -V
> Informix Dynamic Server Version 7.31.FD6     Software Serial Number
> ACP#J[XXXXXX]

> # onstat -p

> Informix Dynamic Server Version 7.31.FD6     -- On-Line -- Up 5 days
> 22:43:36 -- 36752 Kbytes

> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 2391     3442     7434936  99.97   6044     9801     205175   97.05

> isamtot  open     start    read     write    rewrite  delete   commit
> rollbk
> 4734910  88990    398907   3116655  36281    659      493      11406    0

> gp_read  gp_write gp_rewrt gp_del   gp_alloc gp_free  gp_curs
> 0        0        0        0        0        0        0

> ovlock   ovuserthread ovbuff   usercpu  syscpu   numckpts flushes
> 0        0            0        247.72   155.96   8        3428

> bufwaits lokwaits lockreqs deadlks  dltouts  ckpwaits compress seqscans
> 557      0        6124529  0        0        3        120      11203

> ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
> 196      0        196      392        17

> -Darrin
> darrin.wolf  at provia  dot com

> Please just reply to the newsgroup--share the knowledge--thanks!


 
 
 

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

Post by Fernando Nune » Thu, 26 Jun 2003 03:36:07


Check for

DEFINE xpto LIKE  table.column

where table.column is an NCHAR or NVARCHAR

If this is it, please contact your local support.

Regards.

 
 
 

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

Post by Darrin Wol » Thu, 26 Jun 2003 03:50:36


[snip]

Quote:> 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]

- Show quoted text -

Quote:

> -Darrin
> darrin.wolf  at provia  dot com

> Please just reply to the newsgroup--share the knowledge--thanks!

 
 
 

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

Post by Darrin Wol » Thu, 26 Jun 2003 04:02:31



Quote:> Check for

> DEFINE xpto LIKE  table.column

No columns in our entire database are NCHAR or NVARCHAR.  Thanks for the
reply though.
Quote:> where table.column is an NCHAR or NVARCHAR

> If this is it, please contact your local support.

> Regards.

 
 
 

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

Post by Darrin Wol » Fri, 27 Jun 2003 05:49:00



Quote:> Hi guys,

> I'm affraid that I have run into another unsolvable porting problem today.
> We have a 4GL file in one of our libraries that, when built via the 'c4gl'
> INFORMIX script, causes a segmentation fault.

[snip]

This is a known INFORMIX problem on AIX, not sure if it only pertains to 5.2
or 5.x, and/or 4.x, but I am using 5.2 with a 64-bit CPU.

To resolve, you need to obtain a IBM PMR# via tech support, then they will
provide a patch (specific to AIX platform - both 32 and 64 bit
architectures) via an FTP URL.  When I receive that URL, I will follow-up on
comp.databases.informix;comp.unix.aix

-Darrin

 
 
 

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

Post by phreu » Sun, 29 Jun 2003 08:37:14


Quote:

> > I'm affraid that I have run into another unsolvable porting problem
today.
> > We have a 4GL file in one of our libraries that, when built via the
'c4gl'
> > INFORMIX script, causes a segmentation fault.

> [snip]

> This is a known INFORMIX problem on AIX, not sure if it only pertains to
5.2
> or 5.x, and/or 4.x, but I am using 5.2 with a 64-bit CPU.

> To resolve, you need to obtain a IBM PMR# via tech support, then they will
> provide a patch (specific to AIX platform - both 32 and 64 bit
> architectures) via an FTP URL.  When I receive that URL, I will follow-up
on
> comp.databases.informix;comp.unix.aix

Solution:
Enclosed is the software patch intended to address the problem(s) reported
in the PMR #16279,004. Here are the instructions to downloading the patch.
The patch will only remain on the FTP server for 72 hours. From a web
browser click on the following links:
ftp://testcase.boulder.ibm.com/software/fromibm/informix/23812/4gl.tar
ftp://testcase.boulder.ibm.com/software/fromibm/informix/23812/4glrt.tar
 
 
 

1. 'getservbyname' core dumps on second call (sol 2.3 /5.3)

Hi,
I am going to port my app from aix3.2.5 to Solaris 2.3. It is a motif-client
that communicates trough sockets with a server, which runs on rs6k.

To do this, I have to read my service, located in '/etc/services', with
'getservbyname'. The first call works fine but when I try to call it
again, the app crashes.

The same code works on all aix-platforms very well.

When I debug the core, I wonder that my function 'client_connect' does not
call 'getservbyname', the calling stack shows that 'getservbyname_r'
is called. It is the thread-safe variant of 'getservbyname'.
I have also looked in /usr/include/*.h, it is not a macro!

It would be very kindly, if someone out there can help me,
thank you in advance,
        ciao Donato

Here it is the output from dbx:

corefile read successfully
Reading symbolic information for rtld /usr/lib/ld.so.1
Reading symbolic information for /usr/lib/libsocket.so.1
Reading symbolic information for /opt/SUNWmotif/lib/libXm.so.2
Reading symbolic information for /usr/openwin/lib/libXt.so.4
Reading symbolic information for /usr/openwin/lib/libX11.so.4
Reading symbolic information for /usr/lib/libnsl.so.1
Reading symbolic information for /usr/lib/libc.so.1
Reading symbolic information for /usr/lib/libdl.so.1
Reading symbolic information for /usr/lib/libw.so.1
Reading symbolic information for /usr/lib/libintl.so.1
Reading symbolic information for /usr/lib/switch.so
Reading symbolic information for /usr/lib/nss_nisplus.so.1
Reading symbolic information for /usr/lib/nss_files.so.1
program terminated by signal SEGV (segmentation violation)
(dbx) where
 0x116000(0xef7bc314, 0x723e0, 0x0, 0xa, 0x116000, 0x0) at 0x115fff
nss_get_backend_u(0xefffec94, 0x997f0, 0x0, 0x99850, 0x0, 0x1) at 0xef3857b0
nss_search(0x0, 0xef7b49bc, 0x4, 0xefffecb0, 0x0, 0x2) at 0xef385ddc
_switch_getservbyname_r(0x5b8d0, 0xef312d34, 0xfb85c, 0xfb86c, 0x400, 0xfb850) at 0xef7b4a3c
_netdir_getbyname(0xfb7e0, 0xefffee78, 0x4, 0x1, 0x2, 0xef312d34) at 0xef301410
netdir_getbyname(0xfb7e0, 0xefffee78, 0x0, 0x0, 0xf85e0, 0x6e7b0) at 0xef3d8a28
getservbyname_r(0x5b8d0, 0x46e84, 0x98f64, 0x98f74, 0xfb7e0, 0x98f58) at 0xef7b46fc
client_connect(config_file_name = 0x5b890 "$RTSIBCONFIG/client.config", host_name_parameter = 0x5b8ac "serverhost", service_name_parameter = 0x5b8b8 "servicename", port_number_parameter = 0x5b8c4 "serviceport", default_service_name = 0x5b8d0 "rtsibis", default_port = 1240, connected_host = 0xeffff0e8 "", alternate_host = (nil)), line 222 in "../../../lib/SunOS/client.c"
ibis_connect(host_name = 0xeffff0e8 ""), line 75 in "../lib/SunOS/ibisconnect.c"
load_trades(), line 44 in "SunOS/loadtrades.c"
initWidgetTree(applShell = 0x826e0), line 334 in "SunOS/ibistrading.c"
main(argc = 1, argv = 0xeffff49c), line 38 in "SunOS/main.c"

2. If a process is blocked in IPC message queue msqid_ds.wwait or rwait ... ...

3. Q: where is 'dump' and 'restore' for linux?

4. Multilink PPP/MP 0.9

5. 'freq' util for Stealth core dumps under SLS 1.03

6. How can I tell mplayer where w32 codecs dir is?

7. Redhat 5.0 / 'who' dumping core

8. looking for rdump sources

9. core dump with 'finger'

10. 'dbx' core dumps

11. 'more' core dumps

12. Where is my 'core' dump ?

13. segmentation fault w/core dump using 'who' cmd