Skip to content

crash bug in get("function.name")() (PR#1211)

8 messages · Uwe Ligges, Richard M. Heiberger, Peter Dalgaard +2 more

Original
Richard M. Heiberger
# 
R : Copyright 2001, The R Development Core Team
Version 1.3.1  (2001-08-31)
[1] 1 2 3
Levels:  1 2 3
+   print("this is a")
+   NextMethod("print", x, quote = FALSE, right = TRUE, ...)
+ }
function(x,...) {
  print("this is a")
  NextMethod("print", x, quote = FALSE, right = TRUE, ...)
}
[1] "this is a"
[1] 1 2 3
Levels:  1 2 3
[1] "this is a"

Process R exited abnormally with code 5 at Tue Dec 11 16:18:17 2001

----

I am using the windows version rw1031

I also tried on rw1030.   rw1030 gives a different code
Process R exited abnormally with code 255 at Tue Dec 11 17:31:06 2001

Rich

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Uwe Ligges
#
rmh@surfer.sbm.temple.edu wrote:
With an existing workspace the same happens with R-1.4.0 (unstable) on
WinNT4.

Also in R-1.4.0 (unstable) the last lines of your example, if started
without an existing workspace, results in:
[1] "this is a"
[1] 1 2 3
Levels:  1 2 3
[1] "this is a"
Error in get("print.a")(tmp) : function is not a closure
Error: attempt to apply non-function
#### Now a crash!


Uwe
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Peter Dalgaard
# 
Uwe Ligges <ligges@statistik.uni-dortmund.de> writes:
This comes from this spot:

(gdb) 
#3  0x080cc4cc in do_nextmethod (call=0x873cc68, op=0x8214ee8,args=0x873cd2c, 
    env=0x8b2f394) at ../../../R/src/main/objects.c:488
488         s = findFun(CAR(cptr->call), cptr->sysparent);

CAR(cptr->call) grabs the first element of the call. In a construction
like get("print.a")(tmp) that will be  get("print.a"). However, findFun
assumes that it is being passed a symbol, and pokes a HASHVALUE into
what it thinks is the PRINTNAME of the object, and all hell breaks
loose. 

However, given the way that method dispatch works (by "dotting on" the
class name to the function name), I don't think this kind of
construction makes sense at all.  

There probably needs to be a check in findFun that its symbol argument
really is one. It is however of the "Doctor, it hurts when I do this"
variety, and it might be better to keep our hands off it this close to
release time.
Richard M. Heiberger
# 
Peter, your explanation looks right to me, and is certainly consistent
with the crash behavior of
get("print.a")
The R-1.4.0 error message is a good check.

I would think the explanation should prevent the other example from
working as well.  But this one works
get("print.factor")(tmp)
exactly as expected.

Both of these examples work correctly in S-Plus 4.5

Rich
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Peter Dalgaard
# 
Rich Heiberger <rmh@surfer.sbm.temple.edu> writes:
(S-PLUS 3.4 too)

There's no NextMethod in print.factor, but I was wrong on the other
example: It has NextMethod("print",....) with an explicit generic, so
I don't think it should go near the CAR(call) bit at all.

I'll take a closer look, but there's also a few other nasty bugs
nagging us at the moment, and this looks like it could require surgery
to do_nextmethod with some risk of complications.
Luke Tierney
# 
I don't think I'll get to look at this cerefully today, but here is
just a thought: My recollection is that NextMethod needs to be called
only from within a usemethod dispatch because the dispatch needs to
set up stuff in the environment that NextMethod needs.  If you do

print.a <- function(...) NextMethod()

and then call print.a directly then the stuff NextMethod needs isn't
set up, so NextMethod can't do anything useful.  I think the
do_nextmethod tries to detect this and raise an error, but for some
reason it isn't detecting the problem here.

luke
On Wed, Dec 12, 2001 at 02:11:07PM +0100, Peter Dalgaard BSA wrote:

  
    

      
      
    

  


  


      

    

    
1 day later

    

      
      

        


  

        

      Richard M. Heiberger
    

    

      
      #
    

  


  

      
I tried the same exercise in S-Plus 6.  S-Plus 6 rejects any direct use
of a method.  It requires use of the generic.  It provides an error message
that might make sense to us, but probably not to a user.  The message
is consistent with Luke's intuition of coming into the middle of a sequence
that was not properly initiated with UseMethod.

Professional Edition Version 6.0.3 Release 2 for Microsoft Windows : 2001

            

      
      
      
    

        
[1] 1 2 3

            

      
      
      
    

        
Warning messages:
  the "..." object should be a list but has mode "missing"
Problem in NextMethod("print", quote = quote): argument "..1" is missing with no default 
Use traceback() to see the call stack

            

      
      
      
    

        
Warning messages:
  the "..." object should be a list but has mode "missing"
Problem in NextMethod("print", quote = quote): argument "..1" is missing with no default 
Use traceback() to see the call stack

            

      
      
      
    

        
[1] 1 2 3

            

      
      
      
    

        
Rich
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 13 Dec 2001, Rich Heiberger wrote:

        

            

      
      
      
    

        
It only does that for S4-style formal methods, but some care is needed
with S3-style ones.

            

      
      
      
    

        
Well, it works if called properly:

print.factor(tmp, quote = F)
[1] 1 2 3

            

      
      
      
    

        
[1] 1 2 3

The issue is to do with optimizing the evaluation of arguments, and
indeed whether the default is taken from the generic or the method.

Note that `S-Plus 6' is not a single entity: the behaviour of
method dispatch differs between 6.0.y versions.  Later ones are stricter
about argument sequence matching between methods and generics (and that is
why R's QA tools have a strict interpretation too, since they must now be
regarded as `standard S').