Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#51 $t process is killed by system

open
nobody
None
5
2012-12-29
2003-12-22
Dennis Ballance
No

I have encountered very intermittent problems with the
construct "s t=$t(+i^@rName)" where rName is a string
containing the name of a routine. The error has been
noted on 4.3-001E and 4.3-001D, and has not been tested
on newer releases. What happens is when the $t occurs,
the M process is killed with the message
"%GTM-F-KILLBYSIGSINFO1, GT.M process 1690 has been kill
ed by a signal 11 at address 0x4207BEB2 (vaddr
0x418CEF59)". If the construct is changed to "s
t=$t(@("+"_i_"^"_rName))" it works fine. The string is
used in the htRtnS routine of the m2web module, and is
part of a source code viewer for a web browser interface.

This error seems to occur very intermittently, in that
most routine listings display normally, but one listing
out of hundreds will fail. Adding a single character to
the file that is not displaying correctly may (not
guaranteed) result in a normally-displaying file. In
fact, it is so erratic that I have been unable to
generate a test case, because a test case using the
exact same file as causes a problem in the production
environment will work normally in the test. Arg! The
best test case I can provide is to run that $t
construct in a loop where rName is provided as output
from ^%RD.

Let me know if there is more information I can provide.

--Dennis

Discussion

  • Chunling Zhou
    Chunling Zhou
    2003-12-29

    Logged In: YES
    user_id=616633

    Dennis,

    Thanks for reporting this. We are looking into it and trying to
    reproduce it. When this occurs again, could you please send
    us the stack trace output?

    We may ask you more questions when we dig deeper into this.

    Thanks,
    Chunling.

     
  • Logged In: YES
    user_id=204101

    When this has happened, it has been in a web environment,
    where an Apache-launched mumps CGI routine has been
    launched, and that process is what is killed by the kernel
    when the error is encountered. I haven't reproduced it yet
    in a console. In either case, if the process is terminated,
    what is the most effective way to retrieve a stack trace?

    --Dennis

     
  • Steven Estes
    Steven Estes
    2004-01-12

    Logged In: YES
    user_id=97877

    Dennis,

    When you get this error, it should have created a core file.
    If you can post that core file (gzip'd please) some place
    that we can download, we can take a look at the error.

    To answer your question in general though, a stack trace can
    be obtained from the debugger by:

    gdb $gtm_dist/mumps <corefilename>
    (gdb)

    Then at the gdb prompt (which comes after a list of included
    stuff) and the failure description, enter the "where"
    command. Do not put the <> around the core file's name when
    you do the substitution.

    Hope this helps..

    Steve

     
  • Logged In: YES
    user_id=97919

    Dennis,

    It took a while but finally we are able to reproduce this issue
    in-house. Thankfully though our test case is reliably
    reproducible. We have created a change-request to fix this
    issue and will address this in a future release.

    Thanks for reporting as much information as possible about
    the test. It did help in us recreating the failure.

    Thanks,
    Narayanan.

     
  • Logged In: YES
    user_id=204101

    Excellent, and good sleuthing! I have run across it a couple
    more times, most recently last week, although even in that
    case it was oddly sporadic in its behavior (for instance, it
    would occur if I clicked on a link to display a page, but
    not if I manually entered the URL in the browser -- how it
    related to the browser I have no clue).

    I will watch the release notes for indications of its
    correction.

    --Dennis

     
  • Logged In: YES
    user_id=97919

    Dennis,

    The tracking number assigned for this issue is S9D12-
    002412. This is easier to watch out for in the release notes.

    Thanks,
    Narayanan.