From murdoch.duncan at gmail.com  Thu Dec 29 23:50:36 2011
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Thu, 29 Dec 2011 17:50:36 -0500
Subject: [Rd] Crashing R with readline()
In-Reply-To: <4EFCDD7C.7060304@gmail.com>
References: <CAFDcVCTDivB8VxE3Oq+exsyjEc6pc_iEpnVCNu0Bf0YD6X+bQQ@mail.gmail.com>
	<4EFCDD7C.7060304@gmail.com>
Message-ID: <4EFCEEBC.6080002@gmail.com>

On 11-12-29 4:37 PM, Duncan Murdoch wrote:
> On 11-12-29 9:49 AM, Henrik Bengtsson wrote:
>> I get the following with R v2.14.1 patched on Windows 7:
>>
>> % Rterm --vanilla --silent
>>
>>> sessionInfo()
>> R version 2.14.1 Patched (2011-12-26 r58001)
>> Platform: x86_64-pc-mingw32/x64 (64-bit)
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>>> readline(sprintf("%-*s:", 180, "A prompt"))
>> A prompt
>>
>>                                           :
>> [1] ""
>>> q("no")
>> Error: caught access violation - continue with care
>>
>> It is a consistent behavior.
>
> I can reproduce this, but I can't spot where the problem is.  I/O in
> Rterm is very complicated, because we use a getline library that
> implements line editing, and we run the I/O in a thread so that graphics
> windows can be updated while waiting for input.
>
> Presumably the problem is the long prompt causing a buffer overflow
> somewhere, and a workaround is to use a more reasonable length of
> prompt, but I don't think I'm going to be able to offer a real fix.  I'd
> guess this bug is local to Rterm in Windows, but we don't really have
> good tools there to detect buffer overflows.

Just had another idea, and found the problem - a buffer overflow in 
getline.  I'll fix it.

Duncan Murdoch



[Rd] Crashing R with readline()
Duncan Murdoch