[Bug translator/9919] New: array overflow error points to wrong statement

[Bug translator/9919] New: array overflow error points to wrong statement

[mjw at redhat dot com]

An associative array that overflows gives an error which points to the wrong
last statement. Example script:

global count;
global overflow[3];

probe timer.ms(10)
{
  overflow[count++] = gettimeofday_ns();
}

probe timer.s(3)
{
  exit();
}

probe end
{
  foreach (o in overflow)
    printf("%d: %d\n", o, overflow[o]);
}

$ stap overflow.stp 
ERROR: Array overflow, check size limit (3) near identifier 'gettimeofday_ns' at
/usr/share/systemtap/tapset/timestamp.stp:30:10
WARNING: Number of errors: 1, skipped probes: 0

This comes from not updating last_stmt in translate.cxx (visit_arrayindex).
There is an uncommented update already there. Enabling it like so:

diff --git a/translate.cxx b/translate.cxx
index 655937d..ed7556d 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -3892,7 +3892,7 @@ c_unparser_assignment::visit_arrayindex (arrayindex *e)
       else
        {
          mapvar mvar = parent->getmap (array->referent, e->tok);
-         // o->newline() << "c->last_stmt = " << lex_cast_qstring(*e->tok) << "
+         o->newline() << "c->last_stmt = " << lex_cast_qstring(*e->tok) << ";";
          if (op != "=") // don't bother fetch slot if we will just overwrite it
            parent->c_assign (lvar, mvar.get(idx), e->tok);
          c_assignop (res, lvar, rvar, e->tok);

Produces the expected output:

$ /usr/local/systemtap/bin/stap overflow.stp 
ERROR: Array overflow, check size limit (3) near identifier 'overflow' at
overflow.stp:6:3
WARNING: Number of errors: 1, skipped probes: 0

But apparently it was commented out on purpose:

commit 99613db760e3eec1465d85728b35380f8367f9bc
Author: fche <fche>
Date:   Thu Oct 4 03:21:00 2007 +0000

    2007-10-03  Frank Ch. Eigler  <fche@elastic.org>
    
        PR 5102
        * translate.cxx (visit_statement): Add new parameter regarding whether
        c->last_stmt needs to be updated.  Update callers, mostly passing
        "false".
        (visit_EXPRESSIONTYPE): Generally omit setting c->last_stmt, unless
        the construct can set c->last_error.

Needs investigation.

-- 
           Summary: array overflow error points to wrong statement
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=9919

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/9919] array overflow error points to wrong statement

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-03-03 22:24 -------
Yes, array (scalar or statistical) assignment can generate errors,
and thus last_stmt should be set for those cases.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9919

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/9919] array overflow error points to wrong statement

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-03-04 10:59 -------
Fixed with:

commit cd1db1dd034141535648a66d9896db6c5e74dd9e
Author: Mark Wielaard <mjw@redhat.com>
Date:   Wed Mar 4 11:55:56 2009 +0100

    PR9919: Set last_stmt for array (scalar or statistical) assignments.
    
    * translate.cxx (visit_arrayindex): Update last_stmt.
    * testsuite/systemtap.base/overflow_error.exp: New file.
    * testsuite/systemtap.base/overflow_error.stp: Likewise.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=9919

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.