Re: [Rd] [R] Fwd: Help: malloc/free deadlock in unsafe signal handler 'Rf_onsigusr1'

2016-08-03 Thread Ming Li
Thanks luke,

>From your explanation, it seems that the signal SIGUSR1 was only triggered
when user want to break/cancel R execution, so we can't control the time
when SIGUSR1 sent. So for this defect, the best way is to make sure in the
signal handler function, we need to make sure there is no direct/cascade
call malloc/free, if any buffer needed, it is better to keep buffer static
and malloc before calling signal handler.


On Tue, Aug 2, 2016 at 11:39 PM,  wrote:

> Redirecting to R-devel
>
> I don't recall how long the SUGUSR handlers have been in R -- you can
> check in svn if you like -- it's been a long time. The intention is
> for them to serve as an emergency break -- a chance of possibly saving
> the workspace when you get stuck in an infinite loop in C/Fortran code
> that cant be interrupted by a SIGINT. This can't be accomplished
> without doing things that really shouldn't be done in a signal handler.
> That is all these handlers are intended for. If you are using them
> programatically you should rethink what you are doing. If you explain
> what you are trying to do you might get some help with that.
>
> Best,
>
> luke
>
>
> On Tue, 2 Aug 2016, Ming Li wrote:
>
> Thanks luke. cc hawq dev team.
>> I sent this email to R-devel 2 days before forwarding it to R-help, but no
>> one reply.
>>
>> Is there any workaround? When were SIGUSR1 and SIGUSR2 sent in R? Or maybe
>> we should move all operations not too emergency out of signal handler?
>> Thanks.
>>
>> On Tue, Aug 2, 2016 at 4:02 AM,  wrote:
>>   The handlers for SIGUSR1 and SIGUSR2 are really intended as an
>>   emergency break, not for ordinary programming. These could be
>>   rewritten to be safer but that would make them less immediate.
>>
>>   Followups would be more appropriate on R-devel.
>>
>>   Best,
>>
>>   luke
>>
>>   On Mon, 1 Aug 2016, Ming Li wrote:
>>
>>   Hi all,
>>
>>   I am working on a bug,  which running PLR on HAWQ. The
>>   process hung and
>>   can't be terminated.
>>
>> From my investigation, it seems signal handler
>> 'Rf_onsigusr1' trigger a
>>
>>   malloc/free deadlock.
>>
>>   The calling stack is below.
>>
>>   Thread 1 (Thread 0x7f4c93af48e0 (LWP 431263)):
>>   #0  0x7f4c9015805e in __lll_lock_wait_private () from
>>   /lib64/libc.so.6
>>   #1  0x7f4c900dd16b in _L_lock_9503 () from
>>   /lib64/libc.so.6
>>   #2  0x7f4c900da6a6 in malloc () from /lib64/libc.so.6
>>   #3  0x7f4c9008fb39 in _nl_make_l10nflist () from
>>   /lib64/libc.so.6
>>   #4  0x7f4c9008ddf5 in _nl_find_domain () from
>>   /lib64/libc.so.6
>>   #5  0x7f4c9008d6e0 in __dcigettext () from
>>   /lib64/libc.so.6
>>   #6  0x7f4c6fabcfe3 in Rf_onsigusr1 () from
>>   /usr/local/lib64/R/lib/libR.so
>>   #7  
>>   #8  0x7f4c9014079a in brk () from /lib64/libc.so.6
>>   #9  0x7f4c90140845 in sbrk () from /lib64/libc.so.6
>>   #10 0x7f4c900dd769 in __default_morecore () from
>>   /lib64/libc.so.6
>>   #11 0x7f4c900d87a2 in _int_free () from
>>   /lib64/libc.so.6
>>   #12 0x00b3ff24 in gp_free2 ()
>>   #13 0x00b356fc in AllocSetDelete ()
>>   #14 0x00b38391 in MemoryContextDeleteImpl ()
>>   #15 0x0077c851 in ExecEndAgg ()
>>   #16 0x007592ad in ExecEndNode ()
>>   #17 0x0075186c in ExecEndPlan ()
>>   #18 0x0079dffa in ExecEndSubqueryScan ()
>>   #19 0x0075921d in ExecEndNode ()
>>   #20 0x0075186c in ExecEndPlan ()
>>   #21 0x00752565 in ExecutorEnd ()
>>   #22 0x006dd9bd in PortalCleanup ()
>>   #23 0x00b3f077 in AtCommit_Portals ()
>>   #24 0x0051abe5 in CommitTransaction ()
>>   #25 0x0051f1d5 in CommitTransactionCommand ()
>>   #26 0x0099809e in PostgresMain ()
>>   #27 0x008f1031 in BackendStartup ()
>>   #28 0x008f70e0 in PostmasterMain ()
>>   #29 0x007f63da in main ()
>>
>>
>>   I googled and found below info maybe useful to fix it: The
>>   best way to
>>   avoid this kind of deadlock is to Call only
>>   asynchronous-safe functions
>>   within signal handlers.
>>
>>
>> https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+a
>>   synchronous-safe+functions+within+signal+handlers
>>
>>   Thanks a lot.
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more,
>> see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible
>> code.
>>
>>
>> --
>> Luke Tierney
>> Ralph E. Wareham Professor of Mathematical Sciences
>> University of Iowa  

[Rd] seq.int does not return a sequence of integers sometimes

2016-08-03 Thread Paul Johnson
I have a script that goes wrong because I assumed that seq.int would
return integers.

Below please see it does not unless user is super cautious about
inserting "L" with inputs. I think seq.int should do coercion for me
before returning the sequence.

> xx <- seq.int(1,10)
> class(xx)
[1] "integer"
> is.integer(xx)
[1] TRUE
> xx <- seq.int(1,10, 2)
> class(xx)
[1] "numeric"
> is.integer(xx)
[1] FALSE
> xx <- seq.int(1,10, 2L)
> class(xx)
[1] "numeric"
> is.integer(xx)
[1] FALSE
> xx <- seq.int(1L, 10L, 2L)
> class(xx)
[1] "integer"
> is.integer(xx)
[1] TRUE


I think all of those should have same return value, if the function is
correctly named seq.int.

-- 
Paul E. Johnson   http://pj.freefaculty.org
Director, Center for Research Methods and Data Analysis http://crmda.ku.edu

I only use this account for email list memberships. To write directly,
address me at pauljohn at ku.edu.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] seq.int does not return a sequence of integers sometimes

2016-08-03 Thread Marc Schwartz

> On Aug 3, 2016, at 3:12 PM, Paul Johnson  wrote:
> 
> I have a script that goes wrong because I assumed that seq.int would
> return integers.
> 
> Below please see it does not unless user is super cautious about
> inserting "L" with inputs. I think seq.int should do coercion for me
> before returning the sequence.
> 
>> xx <- seq.int(1,10)
>> class(xx)
> [1] "integer"
>> is.integer(xx)
> [1] TRUE
>> xx <- seq.int(1,10, 2)
>> class(xx)
> [1] "numeric"
>> is.integer(xx)
> [1] FALSE
>> xx <- seq.int(1,10, 2L)
>> class(xx)
> [1] "numeric"
>> is.integer(xx)
> [1] FALSE
>> xx <- seq.int(1L, 10L, 2L)
>> class(xx)
> [1] "integer"
>> is.integer(xx)
> [1] TRUE
> 
> 
> I think all of those should have same return value, if the function is
> correctly named seq.int.


Paul,

?seq.int has the following:

under Details:

"seq.int is an internal generic which dispatches on methods for "seq" based on 
the class of the first supplied argument (before argument matching)."

and under Value:

"seq.int and the default method of seq for numeric arguments return a vector of 
type "integer" or "double": programmers should not rely on which."


So:

> is.integer(1)
[1] FALSE

> is.integer(1L)
[1] TRUE

which would seem to explain the behavior that you are observing.

Regards,

Marc Schwartz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] seq.int does not return a sequence of integers sometimes

2016-08-03 Thread Duncan Murdoch

On 03/08/2016 4:12 PM, Paul Johnson wrote:

I have a script that goes wrong because I assumed that seq.int would
return integers.


"int" means "internal", not "integer".  Sometimes you should read the 
documentation.


Duncan Murdoch



Below please see it does not unless user is super cautious about
inserting "L" with inputs. I think seq.int should do coercion for me
before returning the sequence.


xx <- seq.int(1,10)
class(xx)

[1] "integer"

is.integer(xx)

[1] TRUE

xx <- seq.int(1,10, 2)
class(xx)

[1] "numeric"

is.integer(xx)

[1] FALSE

xx <- seq.int(1,10, 2L)
class(xx)

[1] "numeric"

is.integer(xx)

[1] FALSE

xx <- seq.int(1L, 10L, 2L)
class(xx)

[1] "integer"

is.integer(xx)

[1] TRUE


I think all of those should have same return value, if the function is
correctly named seq.int.



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] [FORGED] Re: polypath winding rule with transparency

2016-08-03 Thread Paul Murrell

Hi

Just to clarify, I think this IS a problem with grid.path() as well as 
polypath().


For the example you give, grid.path() diverts to drawing a polygon 
(because there is no 'id' specified), and the NAs in 'x' generate two 
separate polygons, which get drawn one on top of the other.


The correct analogy to the polypath() example is ...

x2 <- matrix(x[!is.na(x)], ncol=2)
grid.path(x2[,1], x2[,2], id=rep(1:2, each=4),
  rule="winding", gp=gpar(="#BEBEBE80"))

... which produces the same (wrong) result as polypath() on Windows.

Also, the grid.path() result for your example is NOT the same as the 
correct result;  we do NOT want a separate shade for the intersecting 
region when the "winding" fill rule is working correctly.  The fill 
should be the same across the union of the square regions (this is what 
Cairo and PDF on Linux produce).


Another data point:  the problem is NOT just a matter of getting the 
rules round the wrong way in the devWindows.c;  using rule="evenodd" 
produces the SAME result as using rule="winding".


One more data point:  this is not JUST a problem with polypath(). 
Creating a self-intersecting polygon and then drawing it, using 
polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE) 
produces exactly the same result.


Sadly, none of that helps to explain why the "winding" rule is not 
working on Windows :(


Thanks for reporting the problem - needs more study to find out what is 
going wrong.


Paul

On 03/08/16 18:47, Michael Sumner wrote:

Hello,

it's probably worth adding that this is not a problem with pathGrob, only
polypath.

This code is sufficient to demonstrate the problem in Windows.

## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
  c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
## only a problem on Windows windows() and png()
plot(x);polypath(x, rule = "winding", col = "#BEBEBE80")

This code shows the same behaviour on different systems/devices.

## no problem on Windows/Linux/PNG/PDF ...
library(grid)
grid.newpage()
pushViewport(viewport(0.5, 0.5, width = 1, height = 1))
grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill =
"#BEBEBE80")))

Cheers, Mike.

On Wed, 3 Aug 2016 at 16:24 Michael Sumner  wrote:


Hi, I see different results in png() and pdf() for polypath() on Windows
when using the "winding" rule

## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
  c(.1, .6, .6, .1, NA, .4, .9, .9, .4))

pfun <- function() {
  plot(x)
  polypath(x * 0.8 + 0.2,  rule = "winding", col = "#BEBEBE80")
  polypath(x,  rule = "winding", col = "#BEBEBE80")
}

## output  "windows.png/pdf" or "unix.png/pdf"
label <- .Platform$OS.type
png(sprintf("%s.png", label))
pfun()
dev.off()
pdf(sprintf("%s.pdf", label))
pfun()
dev.off()


Visually, the result in the "windows.png" file is as if the "evenodd" rule
was specified. All other examples unix.pdf, unix.png, windows.pdf give me
the expected result - which is "all bounded regions shaded grey, with two
tones for the different regions of overlap". The unexpected result is the
completely transparent region.

Is this a known/expected difference on Windows?  I see the unexpected
result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on
Windows.

Cheers, Mike.
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

--

Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel