[Bug translator/6529] New: error() from nested function can be lost

[Bug translator/6529] New: error() from nested function can be lost

[jkenisto at us dot ibm dot com]

In some cases, when a script function calls error(), the error() call
has no apparent effect.

For example, when the following script is invoked with an argument
of 2, the call to error() in report2() is lost.
----- nest.stp -----
/* Usage: stap nest.stp n -- where n = 0, 1, or 2 */
global flag

function report1() {
	if (flag == 1)
		error("error in report1")
	return report2()
}

function report2() {
	error("error in report2")
	return 2
}

probe begin {
	flag = $1
	if (flag == 0)
		error("error in begin")
	printf("report1 returns %d\n", report1())
}

probe timer.sec(2) {
	error("timed out")
}
-----
$ stap nest.stp 0		// This works.
ERROR: error in begin
WARNING: Number of errors: 1, skipped probes: 0
$ stap nest.stp 1		// This works.
ERROR: error in report1
WARNING: Number of errors: 1, skipped probes: 0
$ stap nest.stp 2		// Fails.  Expected "error in report2".
report1 returns 0
ERROR: timed out
WARNING: Number of errors: 1, skipped probes: 0

I see the same results on both i386 and x86_64.

It appears that the effect of the error() call is cancelled by the
statement
	c->last_error = "";
following the call to report2().  The bug seems NOT to occur if
a) the function that calls error() returns no value; or
b) the function that calls error() is called directly from a
probe handler.

This bug breaks reporting of bogus register names by [u_]register()
in tapset/x86_64/registers.stp.

-- 
           Summary: error() from nested function can be lost
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: jkenisto at us dot ibm dot com


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

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

[Bug translator/6529] error() from nested function can be lost

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-16 18:12 -------
Could you paste the -p3 generated file?

-- 


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

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

[Bug translator/6529] error() from nested function can be lost

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2008-05-16 18:58 -------
Created an attachment (id=2741)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2741&action=view)
output from "stap -p3 nest.stp 2"

Here's the -p3 output from my i386 system.

-- 


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

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

[Bug translator/6529] error() from nested function can be lost

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-16 19:08 -------
What's needed is probably this line:

      o->newline() << "if (unlikely (c->last_error)) goto " << outlabel << ";";

in c_unparser::visit_return_statement, just before it hardcodes last_error=""


-- 


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

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

[Bug translator/6529] error() from nested function can be lost

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-16 19:11 -------
(In reply to comment #3)
> What's needed is probably this line:
>       o->newline() << "if (unlikely (c->last_error)) goto " << outlabel << ";";

(with code that computes "outlabel" as per ::visit_statement).

or a call over to visit_statement (this, 1, false) after the return value 
expression has been computed/assigned.


-- 


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

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

[Bug translator/6529] error() from nested function can be lost

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2008-05-28 18:16 -------
(In reply to comment #4)
> (with code that computes "outlabel" as per ::visit_statement).

Frank - can you explain the need for the computed outlabels?  I see the comment
about loops in visit_statement, but it doesn't look like anything special is
happening.

I'm thinking about a cleanup that removes most of the "if (last_error)" checks,
and always use unconditional jumps instead.  I think the only last_error checks
needed are after function calls and at the end of probes.  We should also be
able to get rid of this goofy last_error="" business.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joshua dot i dot stone at
                   |                            |intel dot com


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

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

[Bug translator/6529] error() from nested function can be lost

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-28 18:24 -------
It could be that the outlabel stuff was only essential during the olden days
when global variable locking was done on a per-statement basis, rather than
per-probe as is now.  Errors may be able to just jump out -- though check
carefully the translation of loops, function calls.  (outlabels proper are
still needed for break/continue translation).


-- 


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

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

[Bug translator/6529] error() from nested function can be lost

[joshua dot i dot stone at intel dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |joshua dot i dot stone at
                   |redhat dot com              |intel dot com
             Status|NEW                         |ASSIGNED


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

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