[Rd] [New Patch] Fix disk corruption when writing
Duncan Murdoch
murdoch.duncan at gmail.com
Mon Jul 10 13:13:13 CEST 2017
On 10/07/2017 5:34 AM, Serguei Sokol wrote:
> Le 10/07/2017 à 11:19, Duncan Murdoch a écrit :
>> On 10/07/2017 4:54 AM, Serguei Sokol wrote:
>>> Le 08/07/2017 à 00:54, Duncan Murdoch a écrit :
>>>> I have now committed changes to R-devel (rev 72898) that seem to catch large and small errors. They only give a warning if the error happens when the
>>>> connection is closed, because that can happen asynchronously
>>> For this asynchronous behavior, would not it be more useful to have
>>> the name of the file that failed at closing? If many files were open
>>> during a session and not closed explicitly (yes, bad practice but it
>>> can happen), the warning message doesn't help to understand
>>> which of files were corrupted, e.g.:
>>> > fc=file("/dev/full", "w")
>>> > write.csv("a", file=fc)
>>> > q("yes")
>>> Warning message:
>>> In close.connection(getConnection(set[i])) :
>>> Problem closing connection: No space left on device
>>>
>>> Having only "set[i]" for indication is not very informative, is it?
>>
>> To debug your failure to close fc, reproduce the conditions before the warning was issued, and call showConnections().
> It can help in some cases but in all.
> First, to reproduce the exact condition of failure is not always possible. It could
> happen after a long calculation and the environment that caused
> the failure could evolve meantime. And second, having the list of
> connections still does not say which one (or many) has/have failed as
> we have only "set[i]" not even the connection number (which in turn
> could be not the same between the first failure and a tentative to reproduce it).
>
> Is adding con->description to the warning message problematic in any sens ?
Yes, we don't know if it is still valid after the connection has been
closed. It's just a pointer, whose target is allocated when the
connection is created, and deallocated when it is closed. Using it
after closing could lead to a seg fault.
Duncan
More information about the R-devel
mailing list