Apparently the <expletive deleted> system at the U. of Orcland refused
to transmit the file/attachment "shark.txt". I was informed of this
by
Ivan Krylov who suggested that I put this file up on my web page, and
supply the link. I have uploaded the file; the link is:
https://www.stat.auckland.ac.nz/~rolf/Smash/
as in a previous incarnation of this problem. You should see a link
Shell archive of reprex.
Right click on this link and then on "Save link as". This should
provide the file "shark.txt" that I wanted to transmit to you.
For completeness here is a repeat of my previous message, that was
*supposed* to be accompanied by a "shark.txt" attachment until the UoA
buggered things up. Note that I have re-attached the file "vgo.txt"
to
the present email (but of course *not* the untransmittable file
"shark.txt").
> To all and sundry, near and far,
> Ivan Krylov in particular ....
>
> (The latter being singled out because he was so helpful the last time
> I asked a question on this issue. My apologies to him if I am being a
> pest.)
>
> I have again been beset by a "stack smashing" problem when trying
> to run R code that calls upon dynamically loaded Fortran. I have now
> reached the end of my limited mental resources in trying to solve this
> problem, so I am beseeching R-help to come to my assistance.
>
> I have applied valgrind to try to track down the source of the
> problem. I.e. I started R using "R -d valgrind". The output from
> trying to run my code is in the attached file "vgo.txt". All
that I
> can discern from this output is that something went wrong. The
> "location" of the problem seems to be specified as line 85 in the
> Fortran file "getgl.f", but this is the last line
("end") of that
> file, so this just seems to be saying that there is something wrong,
> somewhere in this file!
>
> I have bundled up all of the components of a reproducible example in a
> "shell archive" that I have named "shark.txt" (which is
attached). To
> investigate the problem:
>
> * unpack the shell archive using "sh shark.txt"
> * create a shared object library using "R CMD SHLIB -o hah.so
*.f"
> * start R using "R -d valgrind"
> * source the file "scr" (from the archive) using
'source("scr")'
>
> The shell archive concept is peculiar to Unix/Linux, but apparently
> there is an application called "ZipZag" which can be used by
Windoze
> users to unpack shell archives (if any such users are interested).
>
> I have gone over and over my code, to the point of madness, looking
> for argument miss-matches in the calls in this code, and for
> screw-ups in the dimension statements, and can find none. They must
> be there somewhere, but I cannot see them. Can anyone help me?
>
> Note that the code in the *.f files is very opaque, since the code was
> originally written in Ratfor and then compiled into Fortran. The
> Ratfor code is much more perspicuous, so I have included the
> corresponding *.r files so as to possibly provide some enlightenment.
> If you have ratfor on your system, you can do things like "ratfor
> getgl.r > getgl.f" to recreate the *.f files.
>
> Thanks for any assistance.
>
> cheers,
>
> Rolf Turner
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vgo.txt
URL:
<https://stat.ethz.ch/pipermail/r-help/attachments/20220411/f0ac89d1/attachment.txt>
Depending on one's dislike for different approaches, it's possible to use AddressSanitizer with R in at least three different ways, probably more. There's the Rocker project providing Docker images of R already built with sanitizer support [1] (but then you have to install Docker), there's compiling R from source with -fsanitize=address in CFLAGS, FFLAGS, MAIN_LDFLAGS [2] (but then you have to compile R from source) and there's the partially manual way I've mentioned before (which involves modifying one's global configuration files and reverting the changes later): 1. Temporarily add the following to ~/.R/Makevars: FFLAGS=-g -Og -fsanitize=address FCFLAGS=-g -Og -fsanitize=address 2. Compile the shared object using: R CMD SHLIB -o hah.so *.f -fsanitize=address 3. Run R as follows: LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.5 R With AddressSanitizer, I get the following stack buffer overflow error message:> xxx <- get.gl(theta.new,sigma,X,y,cf,state,"Dbd",size,nbot,ntop)==================================================================716==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffea5d32458 at pc 0x7f282c38498d bp 0x7ffea5d32 000 sp 0x7ffea5d31ff8 WRITE of size 8 at 0x7ffea5d32458 thread T0 #0 0x7f282c38498c in derivfdbd_ /home/ivan/derivfdbd.f:16 #1 0x7f282c3852d6 in derivf_ /home/ivan/derivf.f:17 #2 0x7f282c385dd3 in getgl_ /home/ivan/getgl.f:19 #3 0x7f282c4e5eec in do_dotCode src/main/dotcode.c:1994 (skipping unrelated stack frames) Address 0x7ffea5d32458 is located in stack of thread T0 at offset 312 in frame #0 0x7f282c385a6f in getgl_ /home/ivan/getgl.f:2 This frame has 7 object(s): [32, 36) 'nd' [96, 104) 'd2aa' [160, 168) 'd2ab' [224, 232) 'd2bb' [288, 296) 'd2f' <== Memory access at offset 312 overflows this variable [352, 360) 'd2u' [416, 424) 'd2zeta' (skipping more unnecessary information) Adding "dimension d2f(kstate,npar,npar)" to getgl.f seems to prevent this or any other error from happening, though I can't judge the calculation results; they could indicate some other problem with memory management. -- Best regards, Ivan [1] https://www.rocker-project.org/images/#additional-images [2] https://cran.r-project.org/doc/manuals/R-exts.html#Using-Address-Sanitizer