Set -o Vi Causes core dump and segmentation fault - Redhat

This is a discussion on Set -o Vi Causes core dump and segmentation fault - Redhat ; ALL: We use a build and customization (B&C) process (a bunch of scripts) to rebuild boxes after we've installed RHEL5. I believe, not completely sure, some kernel changes are made. Problem is after we run our B&C and try to ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Set -o Vi Causes core dump and segmentation fault

  1. Set -o Vi Causes core dump and segmentation fault

    ALL:

    We use a build and customization (B&C) process (a bunch of
    scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    completely sure, some kernel changes are made. Problem is after we
    run our B&C and try to issue a set -o vi command it causes a
    segmentation fault and a core dump.

    [ I just tried this myself.. I logged onto a remote box... issued a
    set -o vi command and nothing happened. The next command I typed,
    "ls", caused the box to kick me out. I returned to the same directory
    and found a core file]


    Testers have reported this doesn't occur before the B&C process. Any
    ideas?

    I apologize if I've left out any pertinent information. I'll try to
    repost it as soon as requested.

    Thanx

  2. Re: Set -o Vi Causes core dump and segmentation fault

    On 09/03/2008 05:47 AM, UKnicks sent:
    > ALL:
    >
    > We use a build and customization (B&C) process (a bunch of
    > scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    > completely sure, some kernel changes are made. Problem is after we
    > run our B&C and try to issue a set -o vi command it causes a
    > segmentation fault and a core dump.
    >
    > [ I just tried this myself.. I logged onto a remote box... issued a
    > set -o vi command and nothing happened. The next command I typed,
    > "ls", caused the box to kick me out. I returned to the same directory
    > and found a core file]
    >
    >
    > Testers have reported this doesn't occur before the B&C process. Any
    > ideas?
    >
    > I apologize if I've left out any pertinent information. I'll try to
    > repost it as soon as requested.
    >
    > Thanx


    Are the systems in question _completely_ updated to RHEL 5.2 before the
    failure occurs?

    What shell is in use at the instant of failure? ($ echo $0)

    A rather short search of Red Hat's Bugzilla hasn't yet found anything
    close to this. However, that doesn't mean I looked in all the right
    places.

    Since more than one script is involved, can this be isolated to a
    particular script? Have the scripts been vetted in previous installations?

    Others will probably ask more pointed questions.

    This is certainly why you're paying Red Hat for support.

    --
    1PW

    @?6A62?FEH9E=6o2@=]4@> [r4o7t]

  3. Re: Set -o Vi Causes core dump and segmentation fault

    On Sep 3, 1:34 pm, 1PW wrote:
    > On 09/03/2008 05:47 AM, UKnicks sent:
    >
    >
    >
    > > ALL:

    >
    > > We use a build and customization (B&C) process (a bunch of
    > > scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    > > completely sure, some kernel changes are made. Problem is after we
    > > run our B&C and try to issue a set -o vi command it causes a
    > > segmentation fault and a core dump.

    >
    > > [ I just tried this myself.. I logged onto a remote box... issued a
    > > set -o vi command and nothing happened. The next command I typed,
    > > "ls", caused the box to kick me out. I returned to the same directory
    > > and found a core file]

    >
    > > Testers have reported this doesn't occur before the B&C process. Any
    > > ideas?

    >
    > > I apologize if I've left out any pertinent information. I'll try to
    > > repost it as soon as requested.

    >
    > > Thanx

    >
    > Are the systems in question _completely_ updated to RHEL 5.2 before the
    > failure occurs?
    >
    > What shell is in use at the instant of failure? ($ echo $0)
    >
    > A rather short search of Red Hat's Bugzilla hasn't yet found anything
    > close to this. However, that doesn't mean I looked in all the right
    > places.
    >
    > Since more than one script is involved, can this be isolated to a
    > particular script? Have the scripts been vetted in previous installations?
    >
    > Others will probably ask more pointed questions.
    >
    > This is certainly why you're paying Red Hat for support.


    >
    > --
    > 1PW
    >
    > @?6A62?FEH9E=6o2@=]4@> [r4o7t]



    Yes the systems are completely upgraded before this error occurs.

    Shell in use when this happens is KSH.

    I'll type set -o vi. NOthing happens..However , No matter what I type
    following this causes segmentation fault.

  4. Re: Set -o Vi Causes core dump and segmentation fault

    On 09/03/2008 11:23 AM, UKnicks sent:
    > On Sep 3, 1:34 pm, 1PW wrote:
    >> On 09/03/2008 05:47 AM, UKnicks sent:
    >>
    >>
    >>
    >>> ALL:
    >>> We use a build and customization (B&C) process (a bunch of
    >>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >>> completely sure, some kernel changes are made. Problem is after we
    >>> run our B&C and try to issue a set -o vi command it causes a
    >>> segmentation fault and a core dump.
    >>> [ I just tried this myself.. I logged onto a remote box... issued a
    >>> set -o vi command and nothing happened. The next command I typed,
    >>> "ls", caused the box to kick me out. I returned to the same directory
    >>> and found a core file]
    >>> Testers have reported this doesn't occur before the B&C process. Any
    >>> ideas?
    >>> I apologize if I've left out any pertinent information. I'll try to
    >>> repost it as soon as requested.
    >>> Thanx

    >> Are the systems in question _completely_ updated to RHEL 5.2 before the
    >> failure occurs?
    >>
    >> What shell is in use at the instant of failure? ($ echo $0)
    >>
    >> A rather short search of Red Hat's Bugzilla hasn't yet found anything
    >> close to this. However, that doesn't mean I looked in all the right
    >> places.
    >>
    >> Since more than one script is involved, can this be isolated to a
    >> particular script? Have the scripts been vetted in previous installations?
    >>
    >> Others will probably ask more pointed questions.
    >>
    >> This is certainly why you're paying Red Hat for support.

    >
    >> --
    >> 1PW
    >>
    >> @?6A62?FEH9E=6o2@=]4@> [r4o7t]

    >
    >
    > Yes the systems are completely upgraded before this error occurs.
    >
    > Shell in use when this happens is KSH.
    >
    > I'll type set -o vi. Nothing happens..However , No matter what I type
    > following this causes segmentation fault.


    FWIW - I switched to the korn shell, in my RHEL 5.2, and then entered:
    # set -o vi and then # ls. I encountered no troubles.

    So - can we get you to try and divide and conquer? I don't know about
    your constraints, priorities, commitments or logistics. Not knowing how
    involved your scripts are, or how many scripts you're running. Are the
    scripts always entered in the same identical sequence?

    Does dmesg, or any of your other logs, give any additional clues?

    Would it be possible to enter the lines in your scripts manually - one
    line at a time, followed by your "set -o vi && ls" sequence such that
    further isolation takes place?

    I know this will take time. An alternative might be one where you
    publish your scripts in a /pub directory on some server for peer
    inspection. If the scripts are very minimal, I suppose others in this
    NG would not object to their publication here.

    --
    1PW

    @?6A62?FEH9E=6o2@=]4@> [r4o7t]

  5. Re: Set -o Vi Causes core dump and segmentation fault

    On Sep 3, 3:11 pm, 1PW wrote:
    > On 09/03/2008 11:23 AM, UKnicks sent:
    >
    >
    >
    > > On Sep 3, 1:34 pm, 1PW wrote:
    > >> On 09/03/2008 05:47 AM, UKnicks sent:

    >
    > >>> ALL:
    > >>> We use a build and customization (B&C) process (a bunch of
    > >>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    > >>> completely sure, some kernel changes are made. Problem is after we
    > >>> run our B&C and try to issue a set -o vi command it causes a
    > >>> segmentation fault and a core dump.
    > >>> [ I just tried this myself.. I logged onto a remote box... issued a
    > >>> set -o vi command and nothing happened. The next command I typed,
    > >>> "ls", caused the box to kick me out. I returned to the same directory
    > >>> and found a core file]
    > >>> Testers have reported this doesn't occur before the B&C process. Any
    > >>> ideas?
    > >>> I apologize if I've left out any pertinent information. I'll try to
    > >>> repost it as soon as requested.
    > >>> Thanx
    > >> Are the systems in question _completely_ updated to RHEL 5.2 before the
    > >> failure occurs?

    >
    > >> What shell is in use at the instant of failure? ($ echo $0)

    >
    > >> A rather short search of Red Hat's Bugzilla hasn't yet found anything
    > >> close to this. However, that doesn't mean I looked in all the right
    > >> places.

    >
    > >> Since more than one script is involved, can this be isolated to a
    > >> particular script? Have the scripts been vetted in previous installations?

    >
    > >> Others will probably ask more pointed questions.

    >
    > >> This is certainly why you're paying Red Hat for support.

    >
    > >> --
    > >> 1PW

    >
    > >> @?6A62?FEH9E=6o2@=]4@> [r4o7t]

    >
    > > Yes the systems are completely upgraded before this error occurs.

    >
    > > Shell in use when this happens is KSH.

    >
    > > I'll type set -o vi. Nothing happens..However , No matter what I type
    > > following this causes segmentation fault.

    >
    > FWIW - I switched to the korn shell, in my RHEL 5.2, and then entered:
    > # set -o vi and then # ls. I encountered no troubles.
    >
    > So - can we get you to try and divide and conquer? I don't know about
    > your constraints, priorities, commitments or logistics. Not knowing how
    > involved your scripts are, or how many scripts you're running. Are the
    > scripts always entered in the same identical sequence?
    >
    > Does dmesg, or any of your other logs, give any additional clues?
    >
    > Would it be possible to enter the lines in your scripts manually - one
    > line at a time, followed by your "set -o vi && ls" sequence such that
    > further isolation takes place?
    >
    > I know this will take time. An alternative might be one where you
    > publish your scripts in a /pub directory on some server for peer
    > inspection. If the scripts are very minimal, I suppose others in this
    > NG would not object to their publication here.
    >
    > --
    > 1PW
    >
    > @?6A62?FEH9E=6o2@=]4@> [r4o7t]



    Tomorrow morning we've decided to split the Build and Customization
    script in half and rebuild before running each half. Then we'll at
    least be able to narrow it down to either the bottom of top half of
    the B&C process. After we find which half the error is in we'll
    divide and conquer that half of the process.

    I'd say we run anywhere from 10-15 scripts, always in the same
    sequence.

    I ran dmesg saw the output, ran the "set -o vi ; ls" command sequence,
    ran dmesg again and saw no difference in the output. Did i do that
    correctly? I also tailed /var/log/messages and nothing was written
    there either. These are the only two places I've checked. If you
    know of any others, I'd be glad to look.


  6. Re: Set -o Vi Causes core dump and segmentation fault

    On 09/03/2008 12:23 PM, UKnicks sent:

    Snip, snip...

    > Tomorrow morning we've decided to split the Build and Customization
    > script in half and rebuild before running each half. Then we'll at
    > least be able to narrow it down to either the bottom of top half of
    > the B&C process. After we find which half the error [it] is in we'll
    > divide and conquer that half of the process.


    Outstanding! Of course Murphy's law shall be invoked... It'll be in
    the portion you didn't run. ;-(

    >
    > I'd say we run anywhere from 10-15 scripts, always in the same
    > sequence.


    Good! Very useful... Don't change.

    >
    > I ran dmesg saw the output, ran the "set -o vi ; ls" command sequence,
    > ran dmesg again and saw no difference in the output. Did i do that
    > correctly?


    As long as another core dump _was_ written - yes. True?

    I also tailed /var/log/messages and nothing was written
    > there either. These are the only two places I've checked. If you
    > know of any others, I'd be glad to look.


    Nothing immediate comes to mind. Perhaps you'll find your own solution
    tomorrow. Even if you do, please post your results for all of us to
    learn from.

    Good luck to you all!

    --
    1PW

    @?6A62?FEH9E=6o2@=]4@> [r4o7t]

  7. Re: Set -o Vi Causes core dump and segmentation fault

    UKnicks wrote:
    > ALL:
    >
    > We use a build and customization (B&C) process (a bunch of
    > scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    > completely sure, some kernel changes are made. Problem is after we
    > run our B&C and try to issue a set -o vi command it causes a
    > segmentation fault and a core dump.
    >
    > [ I just tried this myself.. I logged onto a remote box... issued a
    > set -o vi command and nothing happened. The next command I typed,
    > "ls", caused the box to kick me out. I returned to the same directory
    > and found a core file]
    >
    >
    > Testers have reported this doesn't occur before the B&C process. Any
    > ideas?
    >
    > I apologize if I've left out any pertinent information. I'll try to
    > repost it as soon as requested.
    >
    > Thanx


    'set' is internal to the shell I believe - missing dependancy maybe?
    `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    yacking... Run the ptrace on echo $$ and see if you can get anything in
    a log file somewhere... Just throwing some ideas out.

    JR.


    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  8. Re: Set -o Vi Causes core dump and segmentation fault

    Johnny Rebel wrote:
    > UKnicks wrote:
    >> ALL:
    >>
    >> We use a build and customization (B&C) process (a bunch of
    >> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >> completely sure, some kernel changes are made. Problem is after we
    >> run our B&C and try to issue a set -o vi command it causes a
    >> segmentation fault and a core dump.
    >>
    >> [ I just tried this myself.. I logged onto a remote box... issued a
    >> set -o vi command and nothing happened. The next command I typed,
    >> "ls", caused the box to kick me out. I returned to the same directory
    >> and found a core file]
    >>
    >>
    >> Testers have reported this doesn't occur before the B&C process. Any
    >> ideas?
    >>
    >> I apologize if I've left out any pertinent information. I'll try to
    >> repost it as soon as requested.
    >>
    >> Thanx

    >
    > 'set' is internal to the shell I believe - missing dependancy maybe?
    > `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    > yacking... Run the ptrace on echo $$ and see if you can get anything in
    > a log file somewhere... Just throwing some ideas out.
    >
    > JR.
    >
    >


    Just thinking as well - vi is an alias for vim on Linux, and alias is
    also an internal command. Maybe there is an issue with this somewhere?

    JR.


    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  9. Re: Set -o Vi Causes core dump and segmentation fault

    On 09/03/2008 04:19 PM, Johnny Rebel sent:
    > Johnny Rebel wrote:
    >> UKnicks wrote:
    >>> ALL:
    >>>
    >>> We use a build and customization (B&C) process (a bunch of
    >>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >>> completely sure, some kernel changes are made. Problem is after we
    >>> run our B&C and try to issue a set -o vi command it causes a
    >>> segmentation fault and a core dump.
    >>>
    >>> [ I just tried this myself.. I logged onto a remote box... issued a
    >>> set -o vi command and nothing happened. The next command I typed,
    >>> "ls", caused the box to kick me out. I returned to the same directory
    >>> and found a core file]
    >>>
    >>>
    >>> Testers have reported this doesn't occur before the B&C process. Any
    >>> ideas?
    >>>
    >>> I apologize if I've left out any pertinent information. I'll try to
    >>> repost it as soon as requested.
    >>>
    >>> Thanx

    >> 'set' is internal to the shell I believe - missing dependancy maybe?
    >> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    >> yacking... Run the ptrace on echo $$ and see if you can get anything in
    >> a log file somewhere... Just throwing some ideas out.
    >>
    >> JR.
    >>
    >>

    >
    > Just thinking as well - vi is an alias for vim on Linux, and alias is
    > also an internal command. Maybe there is an issue with this somewhere?
    >
    > JR.
    >
    >


    Good theories JR. Maybe we'll get more information later on Thursday.

    --
    1PW

    @?6A62?FEH9E=6o2@=]4@> [r4o7t]

  10. Re: Set -o Vi Causes core dump and segmentation fault

    1PW wrote:
    > On 09/03/2008 04:19 PM, Johnny Rebel sent:
    >> Johnny Rebel wrote:
    >>> UKnicks wrote:
    >>>> ALL:
    >>>>
    >>>> We use a build and customization (B&C) process (a bunch of
    >>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >>>> completely sure, some kernel changes are made. Problem is after we
    >>>> run our B&C and try to issue a set -o vi command it causes a
    >>>> segmentation fault and a core dump.
    >>>>
    >>>> [ I just tried this myself.. I logged onto a remote box... issued a
    >>>> set -o vi command and nothing happened. The next command I typed,
    >>>> "ls", caused the box to kick me out. I returned to the same directory
    >>>> and found a core file]
    >>>>
    >>>>
    >>>> Testers have reported this doesn't occur before the B&C process. Any
    >>>> ideas?
    >>>>
    >>>> I apologize if I've left out any pertinent information. I'll try to
    >>>> repost it as soon as requested.
    >>>>
    >>>> Thanx
    >>> 'set' is internal to the shell I believe - missing dependancy maybe?
    >>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    >>> yacking... Run the ptrace on echo $$ and see if you can get anything in
    >>> a log file somewhere... Just throwing some ideas out.
    >>>
    >>> JR.
    >>>
    >>>

    >> Just thinking as well - vi is an alias for vim on Linux, and alias is
    >> also an internal command. Maybe there is an issue with this somewhere?
    >>
    >> JR.
    >>
    >>

    >
    > Good theories JR. Maybe we'll get more information later on Thursday.
    >


    Thanks! Although some people get an icky feeling using the trace
    family. Here is hoping the issue gets resolved!

    JR.


    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  11. Re: Set -o Vi Causes core dump and segmentation fault

    On Sep 4, 2:15 pm, Johnny Rebel wrote:
    > 1PW wrote:
    > > On 09/03/2008 04:19 PM, Johnny Rebel sent:
    > >> Johnny Rebel wrote:
    > >>> UKnicks wrote:
    > >>>> ALL:

    >
    > >>>> We use a build and customization (B&C) process (a bunch of
    > >>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    > >>>> completely sure, some kernel changes are made. Problem is after we
    > >>>> run our B&C and try to issue a set -o vi command it causes a
    > >>>> segmentation fault and a core dump.

    >
    > >>>> [ I just tried this myself.. I logged onto a remote box... issued a
    > >>>> set -o vi command and nothing happened. The next command I typed,
    > >>>> "ls", caused the box to kick me out. I returned to the same directory
    > >>>> and found a core file]

    >
    > >>>> Testers have reported this doesn't occur before the B&C process. Any
    > >>>> ideas?

    >
    > >>>> I apologize if I've left out any pertinent information. I'll try to
    > >>>> repost it as soon as requested.

    >
    > >>>> Thanx
    > >>> 'set' is internal to the shell I believe - missing dependancy maybe?
    > >>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    > >>> yacking... Run the ptrace on echo $$ and see if you can get anything in
    > >>> a log file somewhere... Just throwing some ideas out.

    >
    > >>> JR.

    >
    > >> Just thinking as well - vi is an alias for vim on Linux, and alias is
    > >> also an internal command. Maybe there is an issue with this somewhere?

    >
    > >> JR.

    >
    > > Good theories JR. Maybe we'll get more information later on Thursday.

    >
    > Thanks! Although some people get an icky feeling using the trace
    > family. Here is hoping the issue gets resolved!
    >
    > JR.
    >
    > --
    >
    > Bill will have to take Linux from my cold, dead flippers.
    >
    > -Tux.




    OK! After a day of divide and conquer on 18 scripts we have figured
    out who/what the culprit is: Apparently, if your subshell editor is
    different from the parent shell's editor it causes this segmentation
    fault. The offending line was : export EDITOR=emacs in our /etc/
    profile. Our parent shell is bash and the editor is set (by /etc/
    profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
    and then type any command it causes the segmentation fault. However if
    the parent shell's editor (The bash shell) is set to VI , or is unset
    it doesn't cause the error. NO idea why this causes the problem as
    we've had this line in our /etc/profile for YEARS now.


  12. Re: Set -o Vi Causes core dump and segmentation fault

    On 09/04/2008 12:45 PM, UKnicks sent:

    Snip, snip...

    >
    > OK! After a day of divide and conquer on 18 scripts we have figured
    > out who/what the culprit is: Apparently, if your subshell editor is
    > different from the parent shell's editor it causes this segmentation
    > fault. The offending line was : export EDITOR=emacs in our /etc/
    > profile. Our parent shell is bash and the editor is set (by /etc/
    > profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
    > and then type any command it causes the segmentation fault. However if
    > the parent shell's editor (The bash shell) is set to VI , or is unset
    > it doesn't cause the error. NO idea why this causes the problem as
    > we've had this line in our /etc/profile for YEARS now.
    >


    Well Done! All of you folks should be proud of your accomplishment. My
    guess is that a Red Hat RPM fixed something, since May 2008, but also
    may have unknowingly caused a problem elsewhere.

    I scanned Red Hat's bugzilla data base again and failed to find
    something like this. I hope you can take the time to open a trouble
    with Red Hat. Your notification could reach far. FYI:



    Does your operation have something that only works with the Korn shell?

    Have any non-redhat applications/utilities been installed that might
    even come close to an explanation for this?

    You, and your associates, have certainly earned your pay this week.

    --
    1PW

    @?6A62?FEH9E=6o2@=]4@> [r4o7t]

  13. Re: Set -o Vi Causes core dump and segmentation fault

    UKnicks wrote:
    > On Sep 4, 2:15 pm, Johnny Rebel wrote:
    >> 1PW wrote:
    >>> On 09/03/2008 04:19 PM, Johnny Rebel sent:
    >>>> Johnny Rebel wrote:
    >>>>> UKnicks wrote:
    >>>>>> ALL:
    >>>>>> We use a build and customization (B&C) process (a bunch of
    >>>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >>>>>> completely sure, some kernel changes are made. Problem is after we
    >>>>>> run our B&C and try to issue a set -o vi command it causes a
    >>>>>> segmentation fault and a core dump.
    >>>>>> [ I just tried this myself.. I logged onto a remote box... issued a
    >>>>>> set -o vi command and nothing happened. The next command I typed,
    >>>>>> "ls", caused the box to kick me out. I returned to the same directory
    >>>>>> and found a core file]
    >>>>>> Testers have reported this doesn't occur before the B&C process. Any
    >>>>>> ideas?
    >>>>>> I apologize if I've left out any pertinent information. I'll try to
    >>>>>> repost it as soon as requested.
    >>>>>> Thanx
    >>>>> 'set' is internal to the shell I believe - missing dependancy maybe?
    >>>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    >>>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
    >>>>> a log file somewhere... Just throwing some ideas out.
    >>>>> JR.
    >>>> Just thinking as well - vi is an alias for vim on Linux, and alias is
    >>>> also an internal command. Maybe there is an issue with this somewhere?
    >>>> JR.
    >>> Good theories JR. Maybe we'll get more information later on Thursday.

    >> Thanks! Although some people get an icky feeling using the trace
    >> family. Here is hoping the issue gets resolved!
    >>
    >> JR.
    >>
    >> --
    >>
    >> Bill will have to take Linux from my cold, dead flippers.
    >>
    >> -Tux.

    >
    >
    >
    > OK! After a day of divide and conquer on 18 scripts we have figured
    > out who/what the culprit is: Apparently, if your subshell editor is
    > different from the parent shell's editor it causes this segmentation
    > fault. The offending line was : export EDITOR=emacs in our /etc/
    > profile. Our parent shell is bash and the editor is set (by /etc/
    > profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
    > and then type any command it causes the segmentation fault. However if
    > the parent shell's editor (The bash shell) is set to VI , or is unset
    > it doesn't cause the error. NO idea why this causes the problem as
    > we've had this line in our /etc/profile for YEARS now.
    >


    Very cool. Glad you have it fixed, and posted back. How come you are
    using ksh on Linux anyways? I personally go the other way and put bash
    on all Unix systems. That way, most of the things that get changed are
    truly bugs/OS features between different flavours. Plus ksh on Unix
    systems don't come with source code making it difficult to fix anything.
    Just curious why the ksh?

    JR.


    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  14. Re: Set -o Vi Causes core dump and segmentation fault

    On Sep 4, 6:55 pm, Johnny Rebel wrote:
    > UKnicks wrote:
    > > On Sep 4, 2:15 pm, Johnny Rebel wrote:
    > >> 1PW wrote:
    > >>> On 09/03/2008 04:19 PM, Johnny Rebel sent:
    > >>>> Johnny Rebel wrote:
    > >>>>> UKnicks wrote:
    > >>>>>> ALL:
    > >>>>>> We use a build and customization (B&C) process (a bunch of
    > >>>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    > >>>>>> completely sure, some kernel changes are made. Problem is after we
    > >>>>>> run our B&C and try to issue a set -o vi command it causes a
    > >>>>>> segmentation fault and a core dump.
    > >>>>>> [ I just tried this myself.. I logged onto a remote box... issued a
    > >>>>>> set -o vi command and nothing happened. The next command I typed,
    > >>>>>> "ls", caused the box to kick me out. I returned to the same directory
    > >>>>>> and found a core file]
    > >>>>>> Testers have reported this doesn't occur before the B&C process. Any
    > >>>>>> ideas?
    > >>>>>> I apologize if I've left out any pertinent information. I'll try to
    > >>>>>> repost it as soon as requested.
    > >>>>>> Thanx
    > >>>>> 'set' is internal to the shell I believe - missing dependancy maybe?
    > >>>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    > >>>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
    > >>>>> a log file somewhere... Just throwing some ideas out.
    > >>>>> JR.
    > >>>> Just thinking as well - vi is an alias for vim on Linux, and alias is
    > >>>> also an internal command. Maybe there is an issue with this somewhere?
    > >>>> JR.
    > >>> Good theories JR. Maybe we'll get more information later on Thursday.
    > >> Thanks! Although some people get an icky feeling using the trace
    > >> family. Here is hoping the issue gets resolved!

    >
    > >> JR.

    >
    > >> --

    >
    > >> Bill will have to take Linux from my cold, dead flippers.

    >
    > >> -Tux.

    >
    > > OK! After a day of divide and conquer on 18 scripts we have figured
    > > out who/what the culprit is: Apparently, if your subshell editor is
    > > different from the parent shell's editor it causes this segmentation
    > > fault. The offending line was : export EDITOR=emacs in our /etc/
    > > profile. Our parent shell is bash and the editor is set (by /etc/
    > > profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
    > > and then type any command it causes the segmentation fault. However if
    > > the parent shell's editor (The bash shell) is set to VI , or is unset
    > > it doesn't cause the error. NO idea why this causes the problem as
    > > we've had this line in our /etc/profile for YEARS now.

    >
    > Very cool. Glad you have it fixed, and posted back. How come you are
    > using ksh on Linux anyways? I personally go the other way and put bash
    > on all Unix systems. That way, most of the things that get changed are
    > truly bugs/OS features between different flavours. Plus ksh on Unix
    > systems don't come with source code making it difficult to fix anything.
    > Just curious why the ksh?
    >
    > JR.
    >
    > --
    >
    > Bill will have to take Linux from my cold, dead flippers.
    >
    > -Tux.


    Hmmm, I don't have a definite answer for why we use ksh. I think it
    does have something to do with our application though. Its always been
    this way as far as I know. Anyway thanx for the assistance.


  15. Re: Set -o Vi Causes core dump and segmentation fault

    UKnicks wrote:
    > On Sep 3, 1:34 pm, 1PW wrote:
    >> On 09/03/2008 05:47 AM, UKnicks sent:
    >>
    >>
    >>
    >>> ALL:
    >>> We use a build and customization (B&C) process (a bunch of
    >>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >>> completely sure, some kernel changes are made. Problem is after we
    >>> run our B&C and try to issue a set -o vi command it causes a
    >>> segmentation fault and a core dump.
    >>> [ I just tried this myself.. I logged onto a remote box... issued a
    >>> set -o vi command and nothing happened. The next command I typed,
    >>> "ls", caused the box to kick me out. I returned to the same directory
    >>> and found a core file]
    >>> Testers have reported this doesn't occur before the B&C process. Any
    >>> ideas?
    >>> I apologize if I've left out any pertinent information. I'll try to
    >>> repost it as soon as requested.
    >>> Thanx

    >> Are the systems in question _completely_ updated to RHEL 5.2 before the
    >> failure occurs?
    >>
    >> What shell is in use at the instant of failure? ($ echo $0)
    >>
    >> A rather short search of Red Hat's Bugzilla hasn't yet found anything
    >> close to this. However, that doesn't mean I looked in all the right
    >> places.
    >>
    >> Since more than one script is involved, can this be isolated to a
    >> particular script? Have the scripts been vetted in previous installations?
    >>
    >> Others will probably ask more pointed questions.
    >>
    >> This is certainly why you're paying Red Hat for support.

    >
    >> --
    >> 1PW
    >>
    >> @?6A62?FEH9E=6o2@=]4@> [r4o7t]

    >
    >
    > Yes the systems are completely upgraded before this error occurs.
    >
    > Shell in use when this happens is KSH.
    >
    > I'll type set -o vi. NOthing happens..However , No matter what I type
    > following this causes segmentation fault.


    And you're using ksh..... why? It's not well supported for Linux. Can you
    switch to Bash?

  16. Re: Set -o Vi Causes core dump and segmentation fault

    UKnicks wrote:
    > On Sep 4, 6:55 pm, Johnny Rebel wrote:
    >> UKnicks wrote:
    >>> On Sep 4, 2:15 pm, Johnny Rebel wrote:
    >>>> 1PW wrote:
    >>>>> On 09/03/2008 04:19 PM, Johnny Rebel sent:
    >>>>>> Johnny Rebel wrote:
    >>>>>>> UKnicks wrote:
    >>>>>>>> ALL:
    >>>>>>>> We use a build and customization (B&C) process (a bunch of
    >>>>>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
    >>>>>>>> completely sure, some kernel changes are made. Problem is after we
    >>>>>>>> run our B&C and try to issue a set -o vi command it causes a
    >>>>>>>> segmentation fault and a core dump.
    >>>>>>>> [ I just tried this myself.. I logged onto a remote box... issued a
    >>>>>>>> set -o vi command and nothing happened. The next command I typed,
    >>>>>>>> "ls", caused the box to kick me out. I returned to the same directory
    >>>>>>>> and found a core file]
    >>>>>>>> Testers have reported this doesn't occur before the B&C process. Any
    >>>>>>>> ideas?
    >>>>>>>> I apologize if I've left out any pertinent information. I'll try to
    >>>>>>>> repost it as soon as requested.
    >>>>>>>> Thanx
    >>>>>>> 'set' is internal to the shell I believe - missing dependancy maybe?
    >>>>>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
    >>>>>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
    >>>>>>> a log file somewhere... Just throwing some ideas out.
    >>>>>>> JR.
    >>>>>> Just thinking as well - vi is an alias for vim on Linux, and alias is
    >>>>>> also an internal command. Maybe there is an issue with this somewhere?
    >>>>>> JR.
    >>>>> Good theories JR. Maybe we'll get more information later on Thursday.
    >>>> Thanks! Although some people get an icky feeling using the trace
    >>>> family. Here is hoping the issue gets resolved!
    >>>> JR.
    >>>> --
    >>>> Bill will have to take Linux from my cold, dead flippers.
    >>>> -Tux.
    >>> OK! After a day of divide and conquer on 18 scripts we have figured
    >>> out who/what the culprit is: Apparently, if your subshell editor is
    >>> different from the parent shell's editor it causes this segmentation
    >>> fault. The offending line was : export EDITOR=emacs in our /etc/
    >>> profile. Our parent shell is bash and the editor is set (by /etc/
    >>> profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
    >>> and then type any command it causes the segmentation fault. However if
    >>> the parent shell's editor (The bash shell) is set to VI , or is unset
    >>> it doesn't cause the error. NO idea why this causes the problem as
    >>> we've had this line in our /etc/profile for YEARS now.

    >> Very cool. Glad you have it fixed, and posted back. How come you are
    >> using ksh on Linux anyways? I personally go the other way and put bash
    >> on all Unix systems. That way, most of the things that get changed are
    >> truly bugs/OS features between different flavours. Plus ksh on Unix
    >> systems don't come with source code making it difficult to fix anything.
    >> Just curious why the ksh?
    >>
    >> JR.
    >>
    >> --
    >>
    >> Bill will have to take Linux from my cold, dead flippers.
    >>
    >> -Tux.

    >
    > Hmmm, I don't have a definite answer for why we use ksh. I think it
    > does have something to do with our application though. Its always been
    > this way as far as I know. Anyway thanx for the assistance.
    >


    I would suggest investigating that further (using bash that is) - it may
    save you headaches in the future. It is also native to the OS... when
    in Rome...

    No probs.

    JR.


    --

    Bill will have to take Linux from my cold, dead flippers.

    -Tux.

  17. Re: Set -o Vi Causes core dump and segmentation fault

    On 09/05/2008 04:55 AM, UKnicks sent:

    Snip, snip...

    >>> OK! After a day of divide and conquer on 18 scripts we have figured
    >>> out who/what the culprit is: Apparently, if your subshell editor is
    >>> different from the parent shell's editor it causes this segmentation
    >>> fault. The offending line was : export EDITOR=emacs in our /etc/
    >>> profile. Our parent shell is bash and the editor is set (by /etc/
    >>> profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
    >>> and then type any command it causes the segmentation fault. However if
    >>> the parent shell's editor (The bash shell) is set to VI , or is unset
    >>> it doesn't cause the error. NO idea why this causes the problem as
    >>> we've had this line in our /etc/profile for YEARS now.

    >> Very cool. Glad you have it fixed, and posted back. How come you are
    >> using ksh on Linux anyways? I personally go the other way and put bash
    >> on all Unix systems. That way, most of the things that get changed are
    >> truly bugs/OS features between different flavours. Plus ksh on Unix
    >> systems don't come with source code making it difficult to fix anything.
    >> Just curious why the ksh?
    >>
    >> JR.
    >>
    >> --
    >>
    >> Bill will have to take Linux from my cold, dead flippers.
    >>
    >> -Tux.

    >
    > Hmmm, I don't have a definite answer for why we use ksh. I think it
    > does have something to do with our application though. Its always been
    > this way as far as I know. Anyway thanx for the assistance.
    >


    I have really never used ksh nor had I ever contemplated studying it.
    However, it appears as if several features of ksh may have attracted the
    author(s) of one or more of your possible scripts to use this.



    The above shows more than two or three features that may have been
    called upon when writing one or more of your possible scripts.

    I was raised on tcsh myself, and later I converted to bash, but I think
    I would have liked to pick up a few things about ksh before I became too
    set in my ways.

    Again, I do hope you file a trouble with Red Hat for the segmentation
    fault discoveries you've made.

    --
    1PW

    @?6A62?FEH9E=6o2@=]4@> [r4o7t]

+ Reply to Thread