From duncan@research.bell-labs.com  Tue Feb  8 00:25:28 2000
From: duncan@research.bell-labs.com (Duncan Temple Lang)
Date: Mon, 7 Feb 2000 19:25:28 -0500 (EST)
Subject: [Rd] Segmentation fault, devPS.c, 0.99.0 (PR#413)
Message-ID: <200002080025.TAA10262@jessie.research.bell-labs.com>



Just as remote possibility, but a potentially impossible bug source,
Signal 11 errors are often associated with hardware (commonly memory)
errors. Is that in any way a reasonable explanation?

(There are some interesting web pages if you search for signal 11
segmentation.)


Duncan.


> From: Roger.Bivand@nhh.no
> Date: Mon, 7 Feb 2000 22:04:18 +0100 (MET)
> CC: R-bugs@biostat.ku.dk
> Sender: owner-r-devel@stat.math.ethz.ch
> Precedence: bulk
> 
> Full_Name: Roger Bivand
> Version: 0.99.0
> OS: RH Linux 6.1
> Submission from: (NULL) (158.37.60.152)
> 
> 
> I am working on an interface between R and the GRASS geographical information
> system,
> written in R, with no dynamically loaded code. I have written full examples, and
> tested
> then under R 0.90.1, both by entering example() for each function and R CMD
> check, both
> of which worked without problem.
> 
> Under 0.99.0 however, R CMD check gives a segmentation fault, but running the
> examples by hand (X11 not PostScript output) doesn't: 
> 
> Core was generated by `/usr/local/lib/R/bin/R.X11 --vanilla'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
> Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
> Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
> Reading symbols from /usr/lib/libblas.so.2...done.
> Reading symbols from /lib/libm.so.6...done.
> Reading symbols from /usr/lib/libreadline.so.3...done.
> Reading symbols from /usr/lib/libz.so.1...done.
> Reading symbols from /lib/libdl.so.2...done.
> Reading symbols from /usr/lib/libncurses.so.4...done.
> Reading symbols from /lib/libc.so.6...done.
> Reading symbols from /lib/libtermcap.so.2...done.
> Reading symbols from /lib/ld-linux.so.2...done.
> Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
> Reading symbols from /usr/local/lib/R/library/akima/libs/akima.so...done.
> Reading symbols from /usr/local/lib/R/library/MASS/libs/MASS.so...done.
> Reading symbols from /usr/local/lib/R/library/spatial/libs/spatial.so...done.
> Reading symbols from /usr/local/lib/R/library/modreg/libs/modreg.so...done.
> #0  0x4021df2a in _IO_vfprintf (s=0x726b2e78, format=0x811ad81 "ep\n", 
>     ap=0xbfffde18) at vfprintf.c:1024
> 1024	vfprintf.c: No such file or directory.
> #1  0x40225f47 in fprintf (stream=0x726b2e78, format=0x811ad81 "ep\n")
>     at fprintf.c:32
> 32	fprintf.c: No such file or directory.
> (gdb) up
> #2  0x806ca78 in PostScriptEndPage (fp=0x726b2e78) at devPS.c:513
> 513	    fprintf(fp, "ep\n");
> (gdb) up
> #3  0x806d953 in PS_NewPage (dd=0x81df2d0) at devPS.c:1015
> 1015	    if(pd->pageno > 1) PostScriptEndPage(pd->psfp);
> (gdb) up
> #4  0x8087c75 in Rf_GNewPlot (recording=1, ask=-2147483648) at graphics.c:1781
> 1781		    dd->dp.newPage(dd);
> (gdb) up
> #5  0x80a33ab in do_plot_new (call=0x405ba44c, op=0x402e01b8, args=0x409418e0, 
>     env=0x40941944) at plot.c:370
> 370	    dd = GNewPlot(call != R_NilValue, ask);
> (gdb) up
> #6  0x8095765 in do_internal (call=0x405ba4b0, op=0x402d8d00, args=0x405ba49c, 
>     env=0x40941944) at names.c:862
> 862	    args = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env);
> #7  0x807c6a1 in Rf_eval (e=0x405ba4b0, rho=0x40941944) at eval.c:172
> 172		    tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> (gdb) up
> #8  0x807cb40 in Rf_applyClosure (call=0x405b6a7c, op=0x405ba550, 
>     arglist=0x402d8008, rho=0x409437bc, suppliedenv=0x402d8008) at eval.c:342
> 342		PROTECT(tmp = eval(body, newrho));
> (gdb) up
> #9  0x807c7cb in Rf_eval (e=0x405b6a7c, rho=0x409437bc) at eval.c:192
> 192		    tmp = applyClosure(e, op, tmp, rho, R_NilValue);
> (gdb) up
> #10 0x807d4c7 in do_begin (call=0x405b5e88, op=0x402d8954, args=0x405b5e9c, 
>     rho=0x409437bc) at eval.c:639
> 639		    s = eval(CAR(args), rho);
> (gdb) up
> #11 0x807c6a1 in Rf_eval (e=0x405b5e88, rho=0x409437bc) at eval.c:172
> 172		    tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> (gdb) up
> #12 0x807cb40 in Rf_applyClosure (call=0x4094425c, op=0x405b73dc, 
>     arglist=0x40944e00, rho=0x40944540, suppliedenv=0x409442fc) at eval.c:342
> 342		PROTECT(tmp = eval(body, newrho));
> #13 0x8095977 in applyMethod (call=0x4094425c, op=0x405b73dc, args=0x40944e00, 
>     rho=0x40944540, newrho=0x409442fc) at objects.c:68
> 68		ans = applyClosure(call, op, args, rho, newrho);
> (gdb) up
> #14 0x8095e48 in Rf_usemethod (generic=0xbfffe438 "plot", obj=0x4094f5a8, 
>     call=0x405b521c, args=0x402d8008, rho=0x40944540, ans=0xbfffe434)
>     at objects.c:197
> 197		*ans = applyMethod(t, sxp, matchedarg, rho, newrho);
> (gdb) up
> #15 0x8095fd3 in do_usemethod (call=0x405b521c, op=0x402e0a78, 
>     args=0x405b5208, env=0x40944540) at objects.c:251
> 251	    if (usemethod(buf, obj, call, CDR(args), env, &ans) == 1) {
> (gdb) up
> #16 0x807c6a1 in Rf_eval (e=0x405b521c, rho=0x40944540) at eval.c:172
> 172		    tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> (gdb) up
> #17 0x807cd8d in do_if (call=0x405b526c, op=0x402d84f4, args=0x405b5258, 
>     rho=0x40944540) at eval.c:428
> 428		return (eval(CAR(CDR(CDR(args))), rho));
> (gdb) up
> #18 0x807c6a1 in Rf_eval (e=0x405b526c, rho=0x40944540) at eval.c:172
> 172		    tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> 
> The examples do use MASS, spatial, akima, and modreg, and the first three of
> these
> have been REMOVEd and freshly INSTALLed, just in case, but the problem appears
> to
> be in the postscript output. If you might find it useful to see the code, I
> could
> make it available, but I don't think that you really need (!) to install GRASS,
> unless
> you know definitely that you do!
> 
> 
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> 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
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> 



-- 
_______________________________________________________________

Duncan Temple Lang                duncan@research.bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-3217
700 Mountain Avenue, Room 2C-259  fax:    (908)582-3340
Murray Hill, NJ  07974-2070       
         http://cm.bell-labs.com/stat/duncan

      "Languages shape the way we think, and determine what 
       we can think about."        
                                      Benjamin Whorf
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] Segmentation fault, devPS.c, 0.99.0 (PR#413)
Duncan Temple Lang