Skip to content

alpha transparency crashes R

2 messages · Deepayan Sarkar, Paul Murrell

Original
Deepayan Sarkar
# 
I'm forwarding a bug report from Jeff Gove that didn't make it to the list.
-Deepayan

------- Original Message --------
Subject: 	alpha transparency crashes R
Date: 	Fri, 07 Nov 2008 14:32:27 -0500
From: 	jeff gove <jhgove at unh.edu>
To: 	r-bugs at r-project.org


I ran into a problem with R crashing when a certain number of
transparent objects (e.g., symbols) are sent to a PDF output device.
This has happened on R 2.71, 2.7.2 (Fedora 8 and Ububtu 8.04
platforms) and now 2.8.0 (I've only tried Fedora 8). The current
pertinent R system stats are...

R.version
               _
platform       x86_64-redhat-linux-gnu
arch           x86_64
os             linux-gnu
system         x86_64, linux-gnu
status
major          2
minor          8.0
year           2008
month          10
day            20
svn rev        46754
language       R
version.string R version 2.8.0 (2008-10-20)

The following small example program when run with n large enough
(e.g., n=1000) and transparency will crash R...

alphaBomb.r = function(n=100, wantAlpha=T) {
   df = data.frame(a=rnorm(n),b=runif(n))
   if(wantAlpha)
     alpha=runif(n)
   else
     alpha = 1
   j = xyplot(b~a, df, alpha=alpha, pch=19)
   print(j)
   trellis.device('pdf',file='alphaBomb.pdf',version='1.4')
   print(j)
   dev.off()
}

Please note that the crash seems to occur in the dev.off() component,
and that the file actually seems to get written out correctly.  The
trace of the bomb is found below, excluding the memory map. Please
also note that it may be somehow related to grid, as the following
code (supplied by Deepayan Sarkar) using base graphics does not crash
R, even with n=100000...

pdf()
n = 1000
plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 16)
dev.off()

The error trace from the above alphaBomb.r() code is...

R> alphaBomb.r(100)   #this is fine
X11cairo
       2

R> alphaBomb.r(1000,F) #also fine

R> alphaBomb.r(1000)
*** glibc detected *** /usr/lib64/R/bin/exec/R: double free or
corruption (!prev): 0x00000000032c1d90 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3ee8c72832]
/lib64/libc.so.6(cfree+0x8c)[0x3ee8c75f2c]
/usr/lib64/R/library/grDevices/libs/grDevices.so[0x2aaab000b0fc]
/usr/lib64/R/lib/libR.so[0x3d1f48ddd3]
/usr/lib64/R/lib/libR.so[0x3d1f48e2dc]
/usr/lib64/R/lib/libR.so[0x3d1f4ec81c]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so[0x3d1f4bf572]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
/usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
/usr/lib64/R/lib/libR.so[0x3d1f4bf572]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
/usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
/usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x188)[0x3d1f4dc878]
/usr/lib64/R/lib/libR.so[0x3d1f4dcb90]
/usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x3d1f4dcec0]
/usr/lib64/R/bin/exec/R(main+0x1b)[0x40082b]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3ee8c1e074]
/usr/lib64/R/bin/exec/R[0x400729]
======= Memory map: ========
etc...

Please note that R only crashes with PDF output; tiff, png and eps
(even though it doesn't accept transparency) all exit cleanly.

My version of glibc is 2.7.

Thanks, I hope that the problem is already resolved!

Jeff
Paul Murrell
# 
Hi
Deepayan Sarkar wrote:
Grid runs laughing from your puny accusations!
This will tickle the problem too:

plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 19)

The issue appears to be in the PDF device driver, which has a fixed-size
integer array called pd->pos and those larger examples are generating
"too many" different alpha values so that we end up assigning values
out-of-range for that array.

The simple fix is to bump up the initial size of the pd->pos array, but
there is some heuristic code in devPS.c (PDF_NewPage) that appears to be
trying to resize the array on-the-fly based on how many pages are being
generated, so perhaps this needs a bit more thought.

Thanks for the bug report!

Paul