Re: [R-pkg-devel] Secondary Issues getting a package on cran

2025-05-09 Thread Tracy Morrison Sweet 
Hi Ivan,

This is extremely helpful! I appreciate your time and detailed explanation.

Tracy


> On May 8, 2025, at 6:30 PM, Ivan Krylov  wrote:
> 
> В Thu, 8 May 2025 12:01:47 -0400
> Tracy Morrison Sweet  пишет:
> 
>> New submission 
>> Package was archived on CRAN
>> 
>> I’m not sure how to do anything to remove this note.
> 
> This note is to be expected.
> 
>> In process.txt and summary.txt, it says "File: HLSM-Ex.Rout
>> vendor/cigraph/src/constructors/adjacency.c:87:34: runtime error: nan
>> is outside the range of representable values of type ‘long’"
> 
> The link to the original issue that got your package archived is more
> informative because it contains the backtrace and shows the place in
> your examples where the problem happens:
> 
> https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/HLSM/HLSM-Ex.Rout
> 
>>> fixed.fit = HLSMfixedEF(Y = ps.advice.mat, senderCov=ps.node.df,
>> +initialVals = initialVals,priors = priors,
>> +tune = tune,tuneIn = FALSE,dd = 2,niter = niter)
>> core/constructors/adjacency.c:47:26: runtime error: nan is outside
>> the range of representable values of type 'long' #0 0x7f09504c6e4b in
>> igraph_i_adjacency_directed
>> /tmp/Rtmp9HF8V2/R.INSTALL659cd504fd46b/igraph/src/core/constructors/adjacency.c:47:26
>> #1 0x7f09504c5715 in igraph_adjacency
>> /tmp/Rtmp9HF8V2/R.INSTALL659cd504fd46b/igraph/src/core/constructors/adjacency.c:212:9
>> #2 0x7f0950c654a3 in R_igraph_graph_adjacency
>> /tmp/Rtmp9HF8V2/R.INSTALL659cd504fd46b/igraph/src/rinterface_extra.c:4861:3
> 
> The file path is now different, but the issue is most likely the same.
> During a call to HLSMfixedEF(), a matrix containing a NaN value is
> passed to the 'igraph' package, where the NaN is converted to an
> integer:
> 
> https://github.com/igraph/rigraph/blob/9a2816248eb837077b5af28bad7b1b9c0713b128/src/vendor/cigraph/src/constructors/adjacency.c#L87
> 
> Unfortunately, converting a NaN into an integer is undefined behaviour
> according to the C standard. The program is allowed to do literally
> anything, so it caused your package to be archived.
> 
> Ideally, 'igraph' could produce an informative error message upon
> detecting a NaN, but you can avoid the problem on your end by making
> sure that all values in your adjacency matrices are finite before
> calling igraph::graph.adjacency().
> 
> To see the problem for yourself, you'll need a "sanitized" build of R:
> https://cran.r-project.org/doc/manuals/R-exts.html#Using-Undefined-Behaviour-Sanitizer
> 
> Sanitizers are somewhat finicky to use. The container images
> docker.io/rocker/r-devel-ubsan-clang and
> ghcr.io/r-hub/containers/clang-ubsan, or the R-hub service may help.
> 
> Good luck! If this wasn't detailed enough, don't hesitate to ask
> follow-up questions.
> 
> -- 
> Best regards,
> Ivan

Tracy M. Sweet
Associate Professor
HDQM
University of Maryland
tsw...@umd.edu
she/her/hers
UMD Land Acknowledgement 







[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN Submission xgboost 1.7.11.1

2025-05-09 Thread Ivan Krylov via R-package-devel 
В Fri, 9 May 2025 04:22:52 +
jiaming yuan  пишет:

> We are trying to resolve the test failures of XGBoost but so far no
> one has managed to reproduce them locally.
> https://github.com/dmlc/xgboost/issues/11431

One test failure really stands out:

>   Error ('test_feature_weights.R:17:5'): training with feature
> weights works
>   Error in `setinfo.xgb.DMatrix(dmat, names(p), p[[1]])`:
> cannot get data pointer of 'double' objects

This is particularly strange because the internal CHKVEC() function is
supposed to check for REALSXP vectors and pass them through. Such
"impossible" errors could be signs of a protection error. (Well, any
memory corruption, but arbitrary memory corruption is harder to
diagnose, so let's hope it's something to do with the garbage
collector.) Let's run the test suite check using a build of R-devel
compiled with .../configure --enable-strict-barrier.


testthat::test_check("xgboost")
# <...>
# Fatal error: Wrong thread calling 'RunFinalizers'
# Fatal error: Wrong thread calling 'RunFinalizers'
# Fatal error: Wrong thread calling 'RunFinalizers'
# Fatal error: Wrong thread calling 'RunFinalizers'
# Fatal error: Wrong thread calling 'RunFinalizers'
# Segmentation fault

Hmm.

Setting a breakpoint in Rstd_Suicide reveals the mistake. It's not a
protection error; it's R API being called from an OpenMP thread:

#5  ALTVEC_DATAPTR (x=0x2d825f58) at ../../../R/src/main/altrep.c:376
#6  0x7fbbd1e5ed98 in operator() (__closure=,
i=) at xgboost_R.cc:258
#7  dmlc::OMPException::Run, int> (this=0x7fffbfaef760, f=...)
at ./dmlc-core/include/dmlc/common.h:67
#8  
_ZN7xgboost6common11ParallelForIiZ18XGDMatrixSetInfo_REUlmE0_EEvT_iNS0_5SchedET0_._omp_fn.3(void)
 ()
at ./dmlc-core/include/../../src/common/threading_utils.h:208
#9  0x7fbbd4552a0e in gomp_thread_start (xdata=)
at ../../../libgomp/team.c:129
(gdb) frame 5
#5  ALTVEC_DATAPTR (x=0x2d825f58) at ../../../R/src/main/altrep.c:376
376 return ALTVEC_DATAPTR_EX(x, TRUE);
(gdb) call R_inspect(x)
@2d825f58 14 REALSXP g0c0 [REF(65535)]  1 : 9 (expanded)

The code would be better served by calling REAL_RO / INTEGER_RO once
and then using the returned pointer inside the OpenMP threads.

-- 
Best regards,
Ivan

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