Topic
  • 11 replies
  • Latest Post - ‏2012-05-08T18:40:32Z by SystemAdmin
SystemAdmin
SystemAdmin
228 Posts

Pinned topic [b]onmonitor fails - Seg. fault [/b]

‏2007-03-01T13:08:15Z |
I just downloaded the Cheetah beta, read the release notes, and ran the install with no problems (sysmaster build successful). But when I try onmonitor, I get the message "Segmentation fault", yet no core dump, no /tmp diagnostic. There is no significant message (i.e. an "af..." file reference) in the online.log, because thankfully, this problem does not crash ids. The Cheetah keeps on running. Only one thing: online.log reports "Maximum server connections 1". Could this be the problem?

My platform is Linux 2.6.18-1.2798.fc6 on an Athlon 32 bit machine.

Any ideas?
Nick
Updated on 2012-05-08T18:40:32Z at 2012-05-08T18:40:32Z by SystemAdmin
  • andreasl
    andreasl
    28 Posts

    Re: <b>onmonitor fails - Seg. fault </b>

    ‏2007-03-01T22:05:23Z  
    What exact action in onmonitor would get you this SegV?

    Have you set your ulimit the way that a core dump would be written, have you checked your pwd for a core file?
  • SystemAdmin
    SystemAdmin
    228 Posts

    Re: <b>onmonitor fails - Seg. fault </b>

    ‏2007-03-02T02:05:10Z  
    • andreasl
    • ‏2007-03-01T22:05:23Z
    What exact action in onmonitor would get you this SegV?

    Have you set your ulimit the way that a core dump would be written, have you checked your pwd for a core file?
    could you try to reinstall the production again?
  • SystemAdmin
    SystemAdmin
    228 Posts

    Re: <b>onmonitor fails - Seg. fault </b>

    ‏2007-03-02T13:39:24Z  
    • andreasl
    • ‏2007-03-01T22:05:23Z
    What exact action in onmonitor would get you this SegV?

    Have you set your ulimit the way that a core dump would be written, have you checked your pwd for a core file?
    > What exact action in onmonitor would get you this
    > SegV?
    >
    > Have you set your ulimit the way that a core dump
    > would be written, have you checked your pwd for a
    > core file?

    Thanks,Andreas,

    The fault is caused simply by starting onmonitor. I never even get to the visual menu. Instead, it's the Seg. fault message. But note that dbaccess runs with no problem. Also onstat and onmode. Even stranger, I have a trial version of IDS 10+, from the IIUG, on the same platform, and onmonitor works with no such problem. Very strange.

    I'm not sure how a reinstall would change this behavior, and will go on to trying the setting a lower ulimit in hopes of getting error message diagnostics. Good idea.

    Nick
  • andreasl
    andreasl
    28 Posts

    Re: <b>onmonitor fails - Seg. fault </b>

    ‏2007-03-02T13:57:08Z  
    > What exact action in onmonitor would get you this
    > SegV?
    >
    > Have you set your ulimit the way that a core dump
    > would be written, have you checked your pwd for a
    > core file?

    Thanks,Andreas,

    The fault is caused simply by starting onmonitor. I never even get to the visual menu. Instead, it's the Seg. fault message. But note that dbaccess runs with no problem. Also onstat and onmode. Even stranger, I have a trial version of IDS 10+, from the IIUG, on the same platform, and onmonitor works with no such problem. Very strange.

    I'm not sure how a reinstall would change this behavior, and will go on to trying the setting a lower ulimit in hopes of getting error message diagnostics. Good idea.

    Nick
    Hi Nick,

    if you're on Linux, you might have gdb installed on your system. If so, please try the following:

    $ gdb onmonitor
    gdb> r # to run the prog ... and receive the SegV
    gdb> where # once you received the SegV, to get the stack where it crashes

    We do have some suspicion as to what might be causing this SegV and hope to verify/falsify this if you can, please, post this stack.
  • SystemAdmin
    SystemAdmin
    228 Posts

    <b> Re: onmonitor fails - Seg. fault </b>

    ‏2007-03-03T17:05:10Z  
    • andreasl
    • ‏2007-03-02T13:57:08Z
    Hi Nick,

    if you're on Linux, you might have gdb installed on your system. If so, please try the following:

    $ gdb onmonitor
    gdb> r # to run the prog ... and receive the SegV
    gdb> where # once you received the SegV, to get the stack where it crashes

    We do have some suspicion as to what might be causing this SegV and hope to verify/falsify this if you can, please, post this stack.
    OK,

    I set ulimit -c 100 to get a few blocks of core dump data from the onmonitor. That worked and got me some core to run strings on, which looks like the main libs that were in memory at crash time. Gdb was much, much better in terms of tea leaf reading, so I'm attaching the results of strings and gdb. Looks like rdszap() was at the top of the stack when this happened, and going on down, something to do with term. My profile sets INFORMIXTERM=terminfo, and my TERM is set to xterm (and from time to time Linux) for my LCD. onmonitor fails with either setting.

    Thanks,
    Nick

    > Hi Nick,
    >
    > if you're on Linux, you might have gdb installed on
    > your system. If so, please try the following:
    >
    > $ gdb onmonitor
    > gdb> r # to run the prog ... and
    > receive the SegV
    > gdb> where # once you received the SegV,
    > to get the stack where it crashes
    >
    > We do have some suspicion as to what might be causing
    > this SegV and hope to verify/falsify this if you can,
    > please, post this stack.
    Updated on 2007-03-03T17:05:10Z at 2007-03-03T17:05:10Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    228 Posts

    Re: <b>onmonitor fails - Seg. fault </b>

    ‏2007-03-03T17:12:26Z  
    • andreasl
    • ‏2007-03-02T13:57:08Z
    Hi Nick,

    if you're on Linux, you might have gdb installed on your system. If so, please try the following:

    $ gdb onmonitor
    gdb> r # to run the prog ... and receive the SegV
    gdb> where # once you received the SegV, to get the stack where it crashes

    We do have some suspicion as to what might be causing this SegV and hope to verify/falsify this if you can, please, post this stack.
    Sorry about that. I hit enter and off she went. I'm including the output from the gdb and the core strings attachement which may not be as helpful.

    0x08172438 in rdszap ()
    (gdb) where
    #0 0x08172438 in rdszap ()
    #1 0x081755a5 in setterm ()
    #2 0x08173116 in initterm ()
    #3 0x08173226 in initscr ()
    #4 0x08172a74 in rdspinit ()
    #5 0x08166c25 in _efenter ()
    #6 0x08163e2b in _efcscrn ()
    #7 0x0804de19 in main ()

    Thanks for your patience,
    Nick
    > Hi Nick,
    >
    > if you're on Linux, you might have gdb installed on
    > your system. If so, please try the following:
    >
    > $ gdb onmonitor
    > gdb> r # to run the prog ... and
    > receive the SegV
    > gdb> where # once you received the SegV,
    > to get the stack where it crashes
    >
    > We do have some suspicion as to what might be causing
    > this SegV and hope to verify/falsify this if you can,
    > please, post this stack.
  • andreasl
    andreasl
    28 Posts

    Re: <b>onmonitor fails - Seg. fault </b>

    ‏2007-03-03T22:37:22Z  
    Sorry about that. I hit enter and off she went. I'm including the output from the gdb and the core strings attachement which may not be as helpful.

    0x08172438 in rdszap ()
    (gdb) where
    #0 0x08172438 in rdszap ()
    #1 0x081755a5 in setterm ()
    #2 0x08173116 in initterm ()
    #3 0x08173226 in initscr ()
    #4 0x08172a74 in rdspinit ()
    #5 0x08166c25 in _efenter ()
    #6 0x08163e2b in _efcscrn ()
    #7 0x0804de19 in main ()

    Thanks for your patience,
    Nick
    > Hi Nick,
    >
    > if you're on Linux, you might have gdb installed on
    > your system. If so, please try the following:
    >
    > $ gdb onmonitor
    > gdb> r # to run the prog ... and
    > receive the SegV
    > gdb> where # once you received the SegV,
    > to get the stack where it crashes
    >
    > We do have some suspicion as to what might be causing
    > this SegV and hope to verify/falsify this if you can,
    > please, post this stack.
    Hi Nick,

    this stack seems to confirm a suspicion a colleague has already had: we're trying to modify some global char pointer - which is what modern Linux doesn't tolerate any more.

    I'll further clarify this and follow up on this soon!

    Thanks for reporting it. (Frankly I'd never noticed this since I only use good old onmonitor when really forced to ;-))

    Andreas
  • SystemAdmin
    SystemAdmin
    228 Posts

    <b>Re: onmonitor fails - Seg. fault </b>

    ‏2007-03-04T00:58:40Z  
    • andreasl
    • ‏2007-03-03T22:37:22Z
    Hi Nick,

    this stack seems to confirm a suspicion a colleague has already had: we're trying to modify some global char pointer - which is what modern Linux doesn't tolerate any more.

    I'll further clarify this and follow up on this soon!

    Thanks for reporting it. (Frankly I'd never noticed this since I only use good old onmonitor when really forced to ;-))

    Andreas
    Righto. And I felt forced to use onmonitor because it's the quick & dirty way for a lazy guy like me to tweak the config and set up dbspaces. But hey, what about the new web dbadmin tool for Cheetah? Seems like an improvement on onmonitor.

    Anyway, I felt compelled to use it because I have been getting log feedback about increasing rootdbs and the log settings (physical & logical) to allow checkpoints.

    BTW, I thought global references were a no-no. For shame. ;)).

    Thanks for all the good suggestions(and end of thread, unless there's a temporary workaround),
    Nick

    P.S. I will keep with it and send you more, perhaps some irrelevant, comments. Keep up the great work!
  • andreasl
    andreasl
    28 Posts

    Re: <b>Re: onmonitor fails - Seg. fault </b>

    ‏2007-03-05T13:26:58Z  
    Righto. And I felt forced to use onmonitor because it's the quick & dirty way for a lazy guy like me to tweak the config and set up dbspaces. But hey, what about the new web dbadmin tool for Cheetah? Seems like an improvement on onmonitor.

    Anyway, I felt compelled to use it because I have been getting log feedback about increasing rootdbs and the log settings (physical & logical) to allow checkpoints.

    BTW, I thought global references were a no-no. For shame. ;)).

    Thanks for all the good suggestions(and end of thread, unless there's a temporary workaround),
    Nick

    P.S. I will keep with it and send you more, perhaps some irrelevant, comments. Keep up the great work!
    Last post for this one (before we return to all the good news around Cheetah :-)

    This problem finally could be reproduced with us, but with the 32bit Cheetah for Linux only, and only with the INFORMIXTERM=terminfo setting, so there should be an easy workaround (don't set INFORMIXTERM or set it to termcap).

    R&D is looking into this now and I'm pretty sure the next beta drop will do better here.

    Cheers,
    Andreas
  • SystemAdmin
    SystemAdmin
    228 Posts

    <b>Re: onmonitor fails - Seg. fault - A workaround that works </b>

    ‏2007-03-05T14:17:11Z  
    • andreasl
    • ‏2007-03-05T13:26:58Z
    Last post for this one (before we return to all the good news around Cheetah :-)

    This problem finally could be reproduced with us, but with the 32bit Cheetah for Linux only, and only with the INFORMIXTERM=terminfo setting, so there should be an easy workaround (don't set INFORMIXTERM or set it to termcap).

    R&D is looking into this now and I'm pretty sure the next beta drop will do better here.

    Cheers,
    Andreas
    A,

    Thanks to your suggestions, onmonitor is back.

    I tried several TERMs and found altos2 works for me (I have an Acer LCD) with INFORMIXTERM=termcap (terminfo doesn't work in my environment with this TERM).

    Also tried dumb & a few others and onmonitor (and sometimes dbaccess) reported termcap entry too long, and just for kicks here's the error messages for TERM=vt100
    INFORMIXTERM=termcap

    {
    Termcap entry too long
    Too many tc= indirections

    Program stopped at "tb4_main.4gl", line number 71.
    FORMS statement error number -1170.
    The type of your terminal is unknown to the system.

    informix@nick ~$ finderr -1170
    -1170 The type of your terminal is unknown to the system.

    Check the setting of your TERM environment variable and the setting of
    your TERMCAP or TERMINFO environment variable. Check with your system
    administrator if you need help with this action.
    }
    Apologies for drawing this out but I thought this might throw some more light on the problem.

    Thanks again,
    Nick
  • SystemAdmin
    SystemAdmin
    228 Posts

    Re: <b>Re: onmonitor fails - Seg. fault - A workaround that works </b>

    ‏2012-05-08T18:40:32Z  
    A,

    Thanks to your suggestions, onmonitor is back.

    I tried several TERMs and found altos2 works for me (I have an Acer LCD) with INFORMIXTERM=termcap (terminfo doesn't work in my environment with this TERM).

    Also tried dumb & a few others and onmonitor (and sometimes dbaccess) reported termcap entry too long, and just for kicks here's the error messages for TERM=vt100
    INFORMIXTERM=termcap

    {
    Termcap entry too long
    Too many tc= indirections

    Program stopped at "tb4_main.4gl", line number 71.
    FORMS statement error number -1170.
    The type of your terminal is unknown to the system.

    informix@nick ~$ finderr -1170
    -1170 The type of your terminal is unknown to the system.

    Check the setting of your TERM environment variable and the setting of
    your TERMCAP or TERMINFO environment variable. Check with your system
    administrator if you need help with this action.
    }
    Apologies for drawing this out but I thought this might throw some more light on the problem.

    Thanks again,
    Nick
    I solved this problem by:

    $ TERM=vt200;export TERM

    $ onmonitor

    It works!