Bug 14338 - Corruption of TZ variable in memory after some invocations of library()
Corruption of TZ variable in memory after some invocations of library()
Status: RESOLVED FIXED
Product: R
Classification: Unclassified
Component: Windows GUI / Window specific
R 2.11.1 patched
ix86 (32-bit) Windows 32-bit
: P5 normal
Assigned To: R-core
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-16 02:59 UTC by Jeff Newmiller
Modified: 2010-07-20 21:18 UTC (History)
1 user (show)

See Also:


Attachments
Demonstration of bug 14338 with R2.11.1pat (2.72 KB, text/plain)
2010-07-19 22:44 UTC, Jeff Newmiller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Newmiller 2010-07-16 02:59:51 UTC
Windows specific
Does not reproduce on my Ubuntu server

> Sys.setenv( TZ="Etc/GMT+8" )           # do not want to work in daylight time
> sometime <- as.POSIXct( "2010-07-05" ) # no error, valid result
> library(RODBC)                         # some libraries do not trigger bug
> sometime <- as.POSIXct( "2010-07-06" ) # no error, valid result
> library(boguslibrary)                  # one trigger is attempt to load nonexistent library
Error in library(boguslibrary) : 
  there is no package called 'boguslibrary'
sometime <- as.POSIXct( "2010-07-07" )   # error regarding corrupted TZ value
Warning messages:
1: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
2: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
3: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
4: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
5: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
# note corruption of 'E' in in-memory copy of TZ variable
> Sys.getenv("TZ")
         TZ 
"Etc/GMT+8" 
# corruption not found in environment
> library(plyr)           # some valid libraries also trigger this problem
> sometime <- as.POSIXct( "2010-07-08" ) # error regarding corrupted TZ value
Warning messages:
1: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
2: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
3: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
4: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'
5: In structure(.Internal(as.POSIXct(x, tz)), class = c("POSIXt", "POSIXct"),  :
  unknown timezone 'tc/GMT+8'

----

RODBC version 1.3-1
plyr version 1.0.3

> bug.report()
--please do not edit the information below--

R Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = 
 major = 2
 minor = 11.1
 year = 2010
 month = 05
 day = 31
 svn rev = 52157
 language = R
 version.string = R version 2.11.1 (2010-05-31)

Windows XP (build 2600) Service Pack 3

Locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

Search Path:
 .GlobalEnv, package:plyr, package:RODBC, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base
Comment 1 Brian Ripley 2010-07-16 09:15:11 UTC
Works for me.  Is there any evidence that this is R and not the
Windows runtime (which has known problems with environment blocks)?
Comment 2 Jeff Newmiller 2010-07-16 14:51:44 UTC
Brian asks "Is there any evidence..."

Yes, as the bug report indicates, Sys.getenv reports a valid copy of TZ.

This bug is NOT "resolved". At least two installations of R exhibit this problem here.
Comment 3 Duncan Murdoch 2010-07-16 19:20:39 UTC
On 16/07/2010 9:51 AM, r-bugs@r-project.org wrote:
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14338
>
>
>
>
>
> --- Comment #2 from Jeff Newmiller <jdnewmil@dcn.davis.ca.us>  2010-07-16 09:51:44 ---
> Brian asks "Is there any evidence..."
>
> Yes, as the bug report indicates, Sys.getenv reports a valid copy of TZ.
>
> This bug is NOT "resolved". At least two installations of R exhibit this
> problem here.
>
>   


I also can't reproduce it, so I think we'll have to leave it as "NOT 
REPRODUCIBLE".  You'll need to debug it enough to give us something 
reproducible if you want any action.

Duncan Murdoch


Comment 4 Jeff Newmiller 2010-07-16 22:54:57 UTC
Machine 1 (original bug report) : Windows XP Pro SP3

R2.11.1 : Problem
R2.10.1 : Problem
R2.9.2  : No Problem

Machine 2 : Windows XP Pro SP3

R2.11.1 : Problem
R2.9.1  : No Problem

Machine 3 : Windows XP Pro SP3

R2.11.1 : Problem
R2.9.1  : No Problem

Machine 4 : Windows Vista (Build 6000)

R2.11.1 : No Problem

Machine 5a : Windows 7 x64

R2.11.1 : No Problem

Machine 5b : "XP Mode" (Virtual PC on Machine 5a)

R2.11.1 : Problem

----

Multiple computers exhibit problem. (Unlikely to be hardware-specific?)
R2.9.x seems not to have this problem. (Problem within R introduced recently?)
Sys.getenv always seems to return valid values. (Problem not in OS?)
Vista and Win7 do not exhibit the problem. (Different flow-of-control in different OS?)

Duncan and Brian should identify the configurations under which they were not able to reproduce the problem.
Comment 5 Duncan Murdoch 2010-07-17 15:46:54 UTC
On 16/07/2010 5:54 PM, r-bugs@r-project.org wrote:
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14338
> 
> 
> 
> 
> 
> --- Comment #3 from Duncan Murdoch <murdoch@stats.uwo.ca>  2010-07-16 14:20:39 ---
> On 16/07/2010 9:51 AM, r-bugs@r-project.org wrote:
>> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14338
>>
>>
>>
>>
>>
>> --- Comment #2 from Jeff Newmiller <jdnewmil@dcn.davis.ca.us>  2010-07-16 09:51:44 ---
>> Brian asks "Is there any evidence..."
>>
>> Yes, as the bug report indicates, Sys.getenv reports a valid copy of TZ.
>>
>> This bug is NOT "resolved". At least two installations of R exhibit this
>> problem here.
>>
>>   
> 
> I also can't reproduce it, so I think we'll have to leave it as "NOT 
> REPRODUCIBLE".  You'll need to debug it enough to give us something 
> reproducible if you want any action.
> 
> Duncan Murdoch
> 
> --- Comment #4 from Jeff Newmiller <jdnewmil@dcn.davis.ca.us>  2010-07-16 17:54:57 ---
> Machine 1 (original bug report) : Windows XP Pro SP3
> 
> R2.11.1 : Problem
> R2.10.1 : Problem
> R2.9.2  : No Problem
> 
> Machine 2 : Windows XP Pro SP3
> 
> R2.11.1 : Problem
> R2.9.1  : No Problem
> 
> Machine 3 : Windows XP Pro SP3
> 
> R2.11.1 : Problem
> R2.9.1  : No Problem
> 
> Machine 4 : Windows Vista (Build 6000)
> 
> R2.11.1 : No Problem
> 
> Machine 5a : Windows 7 x64
> 
> R2.11.1 : No Problem
> 
> Machine 5b : "XP Mode" (Virtual PC on Machine 5a)
> 
> R2.11.1 : Problem
> 
> ----
> 
> Multiple computers exhibit problem. (Unlikely to be hardware-specific?)
> R2.9.x seems not to have this problem. (Problem within R introduced recently?)
> Sys.getenv always seems to return valid values. (Problem not in OS?)
> Vista and Win7 do not exhibit the problem. (Different flow-of-control in
> different OS?)
> 
> Duncan and Brian should identify the configurations under which they were not
> able to reproduce the problem.


Okay, I have finally managed to see it, on a Win XP SP3 machine in R 
2.10.1.  I don't have 2.11.1 installed on that machine, but I do have 
R-patched and R-devel, and it doesn't appear there.  Do you see it on 
recent builds of R-patched?  I don't see anything mentioned in the bug 
lists for R-2.12.0 or R-2.11.1-patched that would explain the change, 
but it might have been fixed as part of some other change.

Duncan Murdoch


Comment 6 Jeff Newmiller 2010-07-19 22:44:33 UTC
Created attachment 1118 [details]
Demonstration of bug 14338 with R2.11.1pat
Comment 7 Jeff Newmiller 2010-07-19 22:50:09 UTC
(In reply to comment #6)
> Created an attachment (id=1118) [details]
> Demonstration of bug 14338 with R2.11.1pat

Comment I intended to combine with attachment:

I tried downloading R2.11.1 Patched and installing it in a test machine, and the problem occurred (in contrast to Duncan's results).  See bug_report_14338_5b2.txt for results. I did not REMOVE R2.11.1 before running this test. I did remove R2.11.1 after running this test, and when I ran the test again with R2.11.1pat I obtained the same result (problem occurred).

I don't have a build environment configured, so I can't test the dev version.

I still disagree with the declared status of this bug, but none of the available status options seems to apply.
Comment 8 Duncan Murdoch 2010-07-19 23:12:22 UTC
I can reproduce the bug now in R-patched.  I'll look into it.

Not sure how to undo the "RESOLVED STATUS"...  it still shows "NOT REPRODUCIBLE", though that doesn't make sense any more.
Comment 9 Duncan Murdoch 2010-07-20 07:06:25 UTC
On 19/07/2010 6:12 PM, r-bugs@r-project.org wrote:
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14338
> 
> 
> 
> 
> 
> --- Comment #8 from Duncan Murdoch <murdoch@stats.uwo.ca>  2010-07-19 18:12:22 ---
> I can reproduce the bug now in R-patched.  I'll look into it.
> 
> Not sure how to undo the "RESOLVED STATUS"...  it still shows "NOT
> REPRODUCIBLE", though that doesn't make sense any more.
> 


I've found the cause of this and have a fix, but so far I haven't 
committed it, because other problems are causing the checks to fail. 
Should be committed tomorrow.

For the record, the problem was that strptime gets a pointer to the TZ 
environment variable, then changes the environment.  This invalidates 
that pointer, but strptime keeps using it.  The calls to library() just 
happened to cause re-use of that bit of memory in a way that triggered 
the warnings.

I suspet this is the sort of thing that could be easily caught if 
valgrind worked in Windows, but it doesn't.

Duncan Murdoch


Comment 10 Jeff Newmiller 2010-07-20 21:18:06 UTC
Thank you, Duncan. Out of curiosity, POSIX says that "the application shall ensure it does not modify the string pointed to by the getenv function", so was this something that some operating systems were better at protecting themselves against, or was it in Windows-specific application code?

r-bugs@r-project.org wrote:

>https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14338
>
>
>Duncan Murdoch <murdoch@stats.uwo.ca> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             Status|VERIFIED                    |RESOLVED
>         Resolution|NOT REPRODUCIBLE            |FIXED
>
>
>
>
>--- Comment #9 from Duncan Murdoch <murdoch@stats.uwo.ca>  2010-07-20 02:06:25 ---
>On 19/07/2010 6:12 PM, r-bugs@r-project.org wrote:
>> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14338
>> 
>> 
>> 
>> 
>> 
>> --- Comment #8 from Duncan Murdoch <murdoch@stats.uwo.ca>  2010-07-19 18:12:22 ---
>> I can reproduce the bug now in R-patched.  I'll look into it.
>> 
>> Not sure how to undo the "RESOLVED STATUS"...  it still shows "NOT
>> REPRODUCIBLE", though that doesn't make sense any more.
>> 
>
>I've found the cause of this and have a fix, but so far I haven't 
>committed it, because other problems are causing the checks to fail. 
>Should be committed tomorrow.
>
>For the record, the problem was that strptime gets a pointer to the TZ 
>environment variable, then changes the environment.  This invalidates 
>that pointer, but strptime keeps using it.  The calls to library() just 
>happened to cause re-use of that bit of memory in a way that triggered 
>the warnings.
>
>I suspet this is the sort of thing that could be easily caught if 
>valgrind worked in Windows, but it doesn't.
>
>Duncan Murdoch
>
>-- 
>Configure bugmail: https://bugs.r-project.org/bugzilla3/userprefs.cgi?tab=email
>------- You are receiving this mail because: -------
>You reported the bug.


---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.