Professional Web Applications Themes

Memory Fault(coredump) - SCO

I'm hoping to find some help here because I'm pretty stumped. Whenever I try to use the mail command, I get this error: Memory Fault(coredump). This happened pretty much out of the blue. All was working fine, then stopped. I'm still learning SCO and I've never ventured into issues like this, so I'm hoping I can get some help here. TIA Tim...

  1. #1

    Default Memory Fault(coredump)

    I'm hoping to find some help here because I'm pretty stumped.
    Whenever I try to use the mail command, I get this error:
    Memory Fault(coredump).

    This happened pretty much out of the blue. All was working fine, then
    stopped. I'm still learning SCO and I've never ventured into issues
    like this, so I'm hoping I can get some help here.

    TIA
    Tim
    Tim Guest

  2. #2

    Default Re: Memory Fault(coredump)

    Tim wrote:
     

    What operating system and release are you using? Run `uname -X`.

    Try running:

    mail -f /dev/null

    Does this dump core? Normally it would print:

    /dev/null: empty file

    If it behaves normally, I would guess that your mailbox is corrupt in
    some unusual way. When you run `mail` with no arguments, it loads your
    default mailbox (/usr/spool/mail/[username] or $HOME/.mailbox). Examine
    that.
     
    Bela Guest

  3. #3

    Default Re: Memory Fault(coredump)

    Bela Lubkin <com> wrote in message news:<com>... 
    >
    > What operating system and release are you using? Run `uname -X`.
    >
    > Try running:
    >
    > mail -f /dev/null
    >
    > Does this dump core? Normally it would print:
    >
    > /dev/null: empty file
    >
    > If it behaves normally, I would guess that your mailbox is corrupt in
    > some unusual way. When you run `mail` with no arguments, it loads your
    > default mailbox (/usr/spool/mail/[username] or $HOME/.mailbox). Examine
    > that.
    > [/ref]

    One thing about this site (customer of mine)
    mmdf has been disabled and smail is being used (since at least 2 years
    ago)
    which means, mailboxes do not have ^a^a^a^a delimiters
    for reading root's mail I installed mutt
    the -f /dev/null test still coredumps

    OS is 5.0.6 with:
    smp 1.1.1Ga
    osr506a
    ERG712045: crontab security ergfix (ver 2.0.0)
    I don't remember installing erg712045 and I should
    be the only one who ever installed _anything_
    oss635a
    oss642a
    oss646b
    oss648a

    they have sarcheck making a report every night and it does not
    indicate any resource being used up

    I checked for possibly corrupt /bin/mail binary by copying from
    another, working 5.0.6 box temporarily. (and yes I was sure to copy
    the actual binary, not just the symlink:) it coredumped the same way.

    I checked for corrupt mailbox file by deleting it entirely

    meanwhile, mutt works fine, and sending mail by creating mail files
    directly from filePro and catting into /usr/lib/sendmail works fine.
    retrieving mail (including root's) via pop3 onto a pc also works fine.

    just the stock /bin/mail /usr/bin/mail and /usr/bin/mailx fail, and,
    they did used to work.

    I don't have truss. If I installed the devsys unlicenced, would truss
    work?
    Brian Guest

  4. #4

    Default Re: Memory Fault(coredump)

    Brian K. White wrote:
     

    `truss` isn't part of the product until OSR507. You can get it from an
    FTP site (URL was posted recently, use google). `trace` is part of the
    devsys and I think it will work unlicensed. `truss` is more likely to
    work for you, but it's good to have both handy. You're on the right
    track in wanting to try a system call tracer, that's probably where I
    was going to send you next.

    Doing some tracing of my own, I suspect you will find the problem is in
    one of these files:

    /etc/default/lang
    /etc/default/security
    /etc/passwd
    /usr/lib/lang/C/C/C/ctype
    /usr/lib/lang/C/C/C/numeric
    /usr/lib/mail/mailrc
    /usr/mmdf/mmdftailor

    Note, the mail client reads /usr/mmdf/mmdftailor even if MMDF isn't
    installed. That's where it learns that you aren't using ^A^A^A^A
    delimiters, for instance.

    Try:

    mail -n -f /dev/null

    which tells it to ignore /usr/lib/mail/mailrc.
     
    Bela Guest

  5. #5

    Default Re: Memory Fault(coredump)

    Bela Lubkin <com> wrote in message news:<com>... 
    >
    > `truss` isn't part of the product until OSR507. You can get it from an
    > FTP site (URL was posted recently, use google). `trace` is part of the
    > devsys and I think it will work unlicensed. `truss` is more likely to
    > work for you, but it's good to have both handy. You're on the right
    > track in wanting to try a system call tracer, that's probably where I
    > was going to send you next.
    >
    > Doing some tracing of my own, I suspect you will find the problem is in
    > one of these files:
    >
    > /etc/default/lang
    > /etc/default/security
    > /etc/passwd
    > /usr/lib/lang/C/C/C/ctype
    > /usr/lib/lang/C/C/C/numeric
    > /usr/lib/mail/mailrc
    > /usr/mmdf/mmdftailor
    >
    > Note, the mail client reads /usr/mmdf/mmdftailor even if MMDF isn't
    > installed. That's where it learns that you aren't using ^A^A^A^A
    > delimiters, for instance.
    >
    > Try:
    >
    > mail -n -f /dev/null
    >
    > which tells it to ignore /usr/lib/mail/mailrc.
    > [/ref]


    ** chagrin! **

    I had renamed /usr/mmdf to /usr/mmdf.disabled several months ago in a
    despreate measure to halt a runaway <something> by brute force
    measures initially while I tracked down the actual problem. As I
    recall, there were many submit or smtpsrvr processes and they had been
    moved off of mmdf for over a year so as far as I could tell there
    should be no reason for any mmdf binaries to ever run. The things they
    normally use the email server for kept working, so I never remembered
    to go back and restore /usr/mmdf. (obviously I hadn't tested plain
    mail, but then again, they generally never use it and never missed it
    either until an in-house programmer happened to want to use it for
    some simple tests recently. I freely grant that renaming the dir was
    probably an overkill move and I was prepared for that and was ready &
    watching for something to break initially, but when nothing did, I
    felt no pressing need to put the dir back. So now several months later
    in turns out something we never use was broke after all.

    I just restored /usr/mmdf and now /bin/mail works again
    or at least it doesn't crash and shows the correct list of unread
    mail.
    I didn't try to read or write mail since I didn't want to take a
    chance of it messing up the mailbox file.

    However... I'm tempted to rename the mmdf folder again because I
    cannot afford to take chances with sudden extreme load due to a
    misconfigured mmdf wigging out. Too many users, too important a
    customer etc...

    My instructions for installing smail (/usr/local/lib/smail/README.jpr)
    did not mention anything about the mmdftailor file or anything like
    scoadmin that might edit it, and the mmdftailor file does not have
    anything in it that I can see that would tell it anything unusual
    about the formatting of user mailbox files.
    They do say to replace a few files with symlinks to smail and remove
    mmdf from rc2.d, which I did.

    Thanks Much
    Brian Guest

  6. #6

    Default Re: Memory Fault(coredump)

    Brian K. White wrote:
     

    You don't need the whole 'usr'mmdf hierarchy, you just need the file
    /usr/mmdf/mmdftailor to exist and have sane contents. Go ahead and move
    aside the current /usr/mmdf directory, make a new one with same
    permissions, copy the mmdftailor file into it.
     

    If you were installing a system from scratch and intended to use neither
    MMDF nor sendmail, I think the first step would be to tell the install
    to use sendmail. That way it will have already set up a sp
    /usr/mmdf hierarchy with just mmdftailor, configured for a non-MMDF
    mailer.

    Now, I've just tested running /bin/mail on OSR504 and OSR507 systems,
    with /usr/mmdf moved aside, and neither of them dumped core. So I'm not
    really sure why yours is allergic to it. But it remains true that all
    of the mail clients on OSR5 are happier if they can find
    /usr/mmdf/mmdftailor.
     
    Bela Guest

  7. #7

    Default Re: Memory Fault(coredump)

    In article <google.com>,
    Brian K. White <com> wrote: [/ref]
     [/ref][/ref]
     [/ref][/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     

    Just one comment. Installing sendmail doesn't remove the
    control-A headers and trailers unless you also make the changes in
    mmdftailor - unless this behavior has been changed in recent
    releases.

    I say this just in case someone else reads this, puts in sendmail,
    and then wonders why there are still the control-As
     

    Did you mean you used mutt -f /dev/null and not
    mail -f /dev/null?

    Any luck running the admin tool for SCO and verifying all the
    software?


    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  8. #8

    Default Re: Memory Fault(coredump)

    com (Bill Vermillion) wrote in message news:<com>... [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]

    >
    > Just one comment. Installing sendmail doesn't remove the
    > control-A headers and trailers unless you also make the changes in
    > mmdftailor - unless this behavior has been changed in recent
    > releases.
    >
    > I say this just in case someone else reads this, puts in sendmail,
    > and then wonders why there are still the control-As[/ref]

    I said smail not sendmail, which is unconcerned with mmdftailor.
     
    >
    > Did you mean you used mutt -f /dev/null and not
    > mail -f /dev/null?[/ref]

    no, bela said try mail -f /dev/null and I did.
    besides, as was said specifically, mutt works fine, the problem is
    specifically about plain mail/mailx

    methinks you read too fast :)

     

    I did not try that. Putting just mmdftailor back in place caused
    /bin/mail to stop bailing so I don't want to mess with it any more.
    However Bela raised a point that moving /usr/mmdf to the side did not
    cause /bin/mail to crash on his test machine, so something else might
    still be wierd somewhere.
    Brian Guest

Similar Threads

  1. fclose memory fault
    By Jeff in forum UNIX Programming
    Replies: 13
    Last Post: January 20th, 12:14 AM
  2. Memory fault - core dumped on SCO OpenServer
    By Greg Ennis in forum Linux / Unix Administration
    Replies: 5
    Last Post: January 17th, 11:58 PM
  3. dbimport - memory fault
    By Eduardo in forum Informix
    Replies: 9
    Last Post: January 5th, 04:07 PM
  4. Replies: 2
    Last Post: December 23rd, 02:16 AM
  5. newbie: memory fault(core dump)
    By Dermot Paikkos in forum UNIX Programming
    Replies: 2
    Last Post: August 2nd, 07:21 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