Professional Web Applications Themes

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

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

  1. #1

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

    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 X" and a "globals X" 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[]

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

    # 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[]

    # 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!




    Darrin Wolf Guest

  2. #2

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

    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 X" and a "globals X" 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[]

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

    # 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[]

    # 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!




    Darrin Wolf Guest

  3. #3

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

    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.

    Fernando Nunes Guest

  4. #4

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

    In comp.unix.aix Darrin Wolf <phreudhotmail.com> wrote:
    DW> Hi guys,

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

    DW> Here is what it looks like during the build:

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

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


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

    The call stack contains no AIX C library functions. I'm
    removing comp.unix.aix from the Followup-To list.

    Regards,

    Nicholas

    --
    "Why shouldn't I top-post?" [url]http://www.aglami.com/tpfaq.html[/url]
    "Meanings are another story." [url]http://www.ifas.org/wa/glossolalia.html[/url]
    Nicholas Dronen Guest

  5. #5

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

    In comp.unix.aix Darrin Wolf <phreudhotmail.com> wrote:
    DW> Hi guys,

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

    DW> Here is what it looks like during the build:

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

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


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

    The call stack contains no AIX C library functions. I'm
    removing comp.unix.aix from the Followup-To list.

    Regards,

    Nicholas

    --
    "Why shouldn't I top-post?" [url]http://www.aglami.com/tpfaq.html[/url]
    "Meanings are another story." [url]http://www.ifas.org/wa/glossolalia.html[/url]
    Nicholas Dronen Guest

  6. #6

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

    "Darrin Wolf" <phreudhotmail.com> wrote in message
    news:vfgpt98oqcpsf1corp.supernews.com...
    > 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



    Darrin Wolf Guest

  7. #7

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

    "Darrin Wolf" <phreudhotmail.com> wrote in message
    news:vfgpt98oqcpsf1corp.supernews.com...
    > 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



    Darrin Wolf Guest

Similar Threads

  1. Set::Array core dumps in for loop
    By Sisyphos in forum PERL Modules
    Replies: 1
    Last Post: June 9th, 04:11 AM
  2. [PHP-DEV] Shared module problems (core dumps) (under
    By Zeev Suraski in forum PHP Development
    Replies: 0
    Last Post: August 29th, 06:42 PM
  3. [PHP-DEV] PHP dumps core loading extension
    By Bruce Bailey in forum PHP Development
    Replies: 2
    Last Post: July 25th, 07:56 PM
  4. gui smit core dumps only for certain users
    By Michelle DeVault in forum AIX
    Replies: 0
    Last Post: July 18th, 07:43 PM
  5. Replies: 0
    Last Post: June 24th, 06:36 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139