Re: Segfault in dataentry() (PR#391)

About this list Date view Thread view Subject view Author view Other groups

Subject: Re: Segfault in dataentry() (PR#391)
maechler@stat.math.ethz.ch
Date: Sat 01 Jan 2000 - 03:09:20 EST


Message-Id: <199912311709.SAA12673@pubhealth.ku.dk>

>>>>> "PD" == p dalgaard <p.dalgaard@pubhealth.ku.dk> writes:

>> dataentry(0,0)

PD> Program received signal SIGSEGV, Segmentation fault. 0x808991c in
PD> duplicate (s=0x0) at ../../../R/src/main/duplicate.c:42 42 switch
PD> (TYPEOF(s)) {

PD> Apparently that one doesn't get trapped by the no-segfault checks.
PD> Martin?

There's a not-so-short "stop.list" of functions which are *NOT* tested for
segfaults. dataentry (w/ and w/o ".") is among them.
all the interactive ones are, actually.
[[remember: The list was quite a bit shorter, and there were R core
              members who complained...]]

Look in ..../tests/make-no-segfault.R for the statements starting with

 edit.int <- c("fix", "edit", "vi", "emacs", "pico", "xemacs", "xedit")
 misc.int <- c("browser", "bug.report", "menu")
 stop.list[["base"]] <-
    ..

to find all the functions which are *not* tested for seg.faults.

Maybe we (R-core) we should really always have
      R_TESTLOTS=yes
in our environments?

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b25 : Tue 04 Jan 2000 - 14:16:12 EST