[Rd] Very hard to reproduce bug (?) in R-devel

[Winston Chang]

>
> Apologies in advance if this is just stating the obvious, but let me try
> and put some general ideas  on the table.


These are great ideas, thanks.



> - is anything non-deterministic involved? (Doesn't sound so, but...)
>

There was an environment where items were added, and the names of the items
had timestamps. However, I just modified that code to use deterministic
names and the error still happened.


- could it be something with the bytecompiler?
>

I've tried two things. The first was to install the pool package with
--no-byte-compile. In this case the error still happens.

The second was to compile R with `./configure
--enable-byte-compiled-packages=no`.
When I do this, the error does NOT happen. I've tried varying the pool code
in a few different ways to try to provoke the error, but I have not been
able to get it to happen. So it is possible that the compiled base R
packages play some part here.



> - can you get something (_anything_) to trigger the bug (in any variant)
> when running R under gdb? I'm thinking gctorture() etc.
>

Some variations of the code will error without gdb, but will not error with
gdb. I twiddled with the code a bit and now the current version of the code
(f97cfdf) will error under gdb.

I've also run it with gctorture(T) and have not seen this error with that
enabled, but I haven't tested it extensively in this mode. (In a previous
email I mentioned that with gctorture on, I got three different errors in
the tests. I later found that these errors were due to tests having
incorrect assumptions. For example, one test called gc() and expected a
warning, but it incorrectly assumed that a GC event would not have occurred
slightly earlier.)



> - it is odd that you cannot immediately get the same behaviour with R -d
> gdb or valgrind. Are you sure you are actually running the same script in
> the same way?
>

Some versions of the code, but not all, will give the same error under gdb
and valgrind. See above.



> - if you can get a hold of something inside gdb, then there should be some
> potential for backtracking using hardware watchpoints and such. As in: This
> memory location doesn't contain the value I expected; what changed it?
>

I probably don't know enough about R internals or gdb to be useful here.
But if someone wants to try it out, reproducing it as simple as copying and
pasting the first two blocks of code from the README here (assuming you
have Docker installed):
  https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88
It will build a Docker image with the appropriate software installed, and
then run the tests. The README also shows how to run it with gdb.

-Winston

	[[alternative HTML version deleted]]