From sokol at insa-toulouse.fr  Mon Jul 10 15:00:08 2017
From: sokol at insa-toulouse.fr (Serguei Sokol)
Date: Mon, 10 Jul 2017 15:00:08 +0200
Subject: [Rd] [New Patch] Fix disk corruption when writing
In-Reply-To: <49f943c9-2e1f-65a5-dcd9-62e9773e57c0@gmail.com>
References: <CAPXDfF=770SgtaLoMeaF7XGUfj3wFSU6hUn6ZFrds0VnwG_+zA@mail.gmail.com>
 <CA+A1kV5xB3yfD2SnKenrnrfgV6wDObQW8vFMxUVQd2kxTc0BjQ@mail.gmail.com>
 <1093380f-a632-ce28-af21-a87e1a40a8db@gmail.com>
 <8ede4416-7745-e66c-7d2f-53c04f1a9067@insa-toulouse.fr>
 <fe2b1e03-2f57-820e-6226-217be4184907@insa-toulouse.fr>
 <0783f593-8624-6f3f-7c54-eb3ab2938a48@insa-toulouse.fr>
 <42077a0f-0e88-8400-8310-afaaa5ef6f9e@gmail.com>
 <ed2899b8-f945-1dad-348a-cee0f8614ba7@insa-toulouse.fr>
 <e8804ff7-473f-3b89-fa65-c1b0d79d85e3@gmail.com>
 <e1cf1c31-2e7c-72cb-453f-68df8321cc3f@insa-toulouse.fr>
 <8ca82104-19ae-a7be-d27f-9f2982b63140@gmail.com>
 <ce8dbd19-c6f1-fcf0-c9af-fccc27eb37c8@insa-toulouse.fr>
 <02239f51-3592-d3f3-5f4a-f479b35b4da9@gmail.com>
 <a5920916-a708-14d3-0e0f-66e5f35f7871@gmail.com>
 <ce5bb61d-0eb4-cc7d-49ec-d43b8de14eab@insa-toulouse.fr>
 <a974c35e-aadb-c9b7-af70-f486e3c24dd2@gmail.com>
 <1631c430-ce0a-ff60-6b22-cdacfc1a80b6@insa-toulouse.fr>
 <49f943c9-2e1f-65a5-dcd9-62e9773e57c0@gmail.com>
Message-ID: <92cd247a-52d7-d862-f5aa-509a62cc46a1@insa-toulouse.fr>

Le 10/07/2017 ? 13:13, Duncan Murdoch a ?crit :
> 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. 
If you mean "free(con->description);" which is in con_close1() at connections.c:3536
it occurs after calling checkClose(). Then logically, con-description is still valid
during generation of warning message.

Serguei.



[Rd] [New Patch] Fix disk corruption when writing
Serguei Sokol