[Pharo-project] cannot modify class comments on Linux
Hi, if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem. Cheers, -- Pavel
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment? 2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
Hi, what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376 -- Pavel On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com>wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
I'm on 64-bit Ubuntu 12.04 2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com>wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04. -- Pavel On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com>wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com
wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
Reproduced on Ubuntu 13.04. Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation). Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04. -- Pavel On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com<mailto:giseladecuzzi@gmail.com>> wrote: I'm on 64-bit Ubuntu 12.04 2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com<mailto:pavel.krivanek@gmail.com>> Hi, what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376 -- Pavel On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com<mailto:giseladecuzzi@gmail.com>> wrote: Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment? 2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com<mailto:pavel.krivanek@gmail.com>> Hi, if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem. Cheers, -- Pavel
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut: Cheers, -- Pavel On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr>wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ------------------------------ *De :* pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] *Date d'envoi :* jeudi 25 avril 2013 21:32 *Ã :* Pharo-project@lists.gforge.inria.fr *Objet :* Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com>wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi < giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
Yes, adding self flush solves the problem. Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : vendredi 26 avril 2013 10:27 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut: Cheers, -- Pavel On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Reproduced on Ubuntu 13.04. Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation). Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] de la part de Pavel Krivanek [pavel.krivanek@gmail.com<mailto:pavel.krivanek@gmail.com>] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Objet : Re: [Pharo-project] cannot modify class comments on Linux Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04. -- Pavel On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com<mailto:giseladecuzzi@gmail.com>> wrote: I'm on 64-bit Ubuntu 12.04 2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com<mailto:pavel.krivanek@gmail.com>> Hi, what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376 -- Pavel On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com<mailto:giseladecuzzi@gmail.com>> wrote: Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment? 2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com<mailto:pavel.krivanek@gmail.com>> Hi, if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem. Cheers, -- Pavel
Right. That would make the .changes file shorter than expected! frank On 26 April 2013 09:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
And you see things appearing in the wrong order inside, as well. Like the start of image line appearing after the new comment change :( Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Frank Shearar [frank.shearar@gmail.com] Date d'envoi : vendredi 26 avril 2013 10:33 Ã : Pharo Development Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux Right. That would make the .changes file shorter than expected! frank On 26 April 2013 09:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
https://pharo.fogbugz.com/default.asp?10411 On Fri, Apr 26, 2013 at 10:37 AM, GOUBIER Thierry <thierry.goubier@cea.fr>wrote:
And you see things appearing in the wrong order inside, as well.
Like the start of image line appearing after the new comment change :(
Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Frank Shearar [ frank.shearar@gmail.com] Date d'envoi : vendredi 26 avril 2013 10:33 Ã : Pharo Development Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux
Right. That would make the .changes file shorter than expected!
frank
On 26 April 2013 09:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr
wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the
last
operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi < giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason
why
the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems
to work
well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
can you add me to the Pharo30Inbox? (PavelKrivanek) :-) -- Pave On Fri, Apr 26, 2013 at 10:44 AM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
https://pharo.fogbugz.com/default.asp?10411
On Fri, Apr 26, 2013 at 10:37 AM, GOUBIER Thierry <thierry.goubier@cea.fr>wrote:
And you see things appearing in the wrong order inside, as well.
Like the start of image line appearing after the new comment change :(
Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Frank Shearar [frank.shearar@gmail.com] Date d'envoi : vendredi 26 avril 2013 10:33 Ã : Pharo Development Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux
Right. That would make the .changes file shorter than expected!
frank
On 26 April 2013 09:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry < thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is
the last
operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi < giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a
32-bit
Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me.
(just
try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it
seems to work
well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
can we assign more tags to one issue? And where is some status like fixReviewNeeded? -- Pavel On Fri, Apr 26, 2013 at 11:31 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2013-04-26, at 10:45, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
can you add me to the Pharo30Inbox? (PavelKrivanek) :-)
done
Issues on fogbugz have 3 global states: 1. OPENED 2. RESOLVED 3. CLOSED OPENED: - add description - reported issue => add a slice information and put the issue on RESOLVED RESOLVED: - workneeded / review needed / fix to include after that the issue might be closed by the integrators On 2013-04-26, at 11:46, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
can we assign more tags to one issue? And where is some status like fixReviewNeeded?
-- Pavel
On Fri, Apr 26, 2013 at 11:31 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2013-04-26, at 10:45, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
can you add me to the Pharo30Inbox? (PavelKrivanek) :-)
done
aahhh, the button Resolve... thanks :-) -- Pavel On Fri, Apr 26, 2013 at 11:53 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
Issues on fogbugz have 3 global states: 1. OPENED 2. RESOLVED 3. CLOSED
OPENED: - add description - reported issue
=> add a slice information and put the issue on RESOLVED RESOLVED: - workneeded / review needed / fix to include
after that the issue might be closed by the integrators
On 2013-04-26, at 11:46, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
can we assign more tags to one issue? And where is some status like fixReviewNeeded?
-- Pavel
On Fri, Apr 26, 2013 at 11:31 AM, Camillo Bruni <camillobruni@gmail.com wrote:
On 2013-04-26, at 10:45, Pavel Krivanek <pavel.krivanek@gmail.com>
wrote:
can you add me to the Pharo30Inbox? (PavelKrivanek) :-)
done
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
This is nasty one. What i worry that it affects much more than code working with .changes file.
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
On 26 Apr 2013, at 12:44, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
This is nasty one. What i worry that it affects much more than code working with .changes file.
Why ? Isn't that standard behavior/semantics: unless you flush you cannot be sure anything is actually out of the OS' buffers. And even then, disks and RAID cards are known to lie and sometimes don't write data out even when flush is called. In networking (TCP streams) this is similar.
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
On 26 April 2013 13:15, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Apr 2013, at 12:44, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
This is nasty one. What i worry that it affects much more than code working with .changes file.
Why ? Isn't that standard behavior/semantics: unless you flush you cannot be sure anything is actually out of the OS' buffers. And even then, disks and RAID cards are known to lie and sometimes don't write data out even when flush is called.
well, it have to be so.. but if it breaks existing code, then it could mean that libc turned from implicit caching/buffering to explicit one. And this could mean many changes here and there. (Besides of that, i never liked RemoteString and other things related to writing to .changes file... that code begs for proper rewrite)
In networking (TCP streams) this is similar.
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
well, it have to be so.. but if it breaks existing code, then it could mean that libc turned from implicit caching/buffering to explicit one. And this could mean many changes here and there. (Besides of that, i never liked RemoteString and other things related to writing to .changes file... that code begs for proper rewrite)
The whole .changes and .source code is extremely complicated considering for what it gets us. Marcus
Hi Sven, On Fri, Apr 26, 2013 at 4:15 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Apr 2013, at 12:44, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
This is nasty one. What i worry that it affects much more than code working with .changes file.
Why ? Isn't that standard behavior/semantics: unless you flush you cannot be sure anything is actually out of the OS' buffers. And even then, disks and RAID cards are known to lie and sometimes don't write data out even when flush is called.
But the issue is whether the read is through the same file pointer as the write or not. If the read is made through the same file pointer (or a dup'ed file pointer) then the data should be in the buffer and the read should see it, and if so, then this is a bug in either glibc (if the FILE * info is not properly synchronised) or (unlikely) the kernel. If it is through a separate file pointer then yes, the problem is a missing flush. Which is it?
In networking (TCP streams) this is similar.
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry < thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is
the last
operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi < giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a
32-bit
Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me.
(just
try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it
seems to work
well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
-- best, Eliot
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ? If 1), then this is probably our fault. If 2), then I wouldn't expect such behaviour. 2013/4/26 Sven Van Caekenberghe <sven@stfx.eu>
On 26 Apr 2013, at 12:44, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
This is nasty one. What i worry that it affects much more than code working with .changes file.
Why ? Isn't that standard behavior/semantics: unless you flush you cannot be sure anything is actually out of the OS' buffers. And even then, disks and RAID cards are known to lie and sometimes don't write data out even when flush is called.
In networking (TCP streams) this is similar.
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry < thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is
the last
operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi < giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a
32-bit
Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me.
(just
try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it
seems to work
well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote:
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ?
If 1), then this is probably our fault. If 2), then I wouldn't expect such behavior.
1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread. Cheers, Henry
I confirm, it's 1) Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method). I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition. Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen@veloxit.no] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote:
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ?
If 1), then this is probably our fault. If 2), then I wouldn't expect such behavior.
1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread. Cheers, Henry
I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used... But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts? Nicolas 2013/4/30 GOUBIER Thierry <thierry.goubier@cea.fr>
I confirm, it's 1)
Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method).
I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition.
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen@veloxit.no] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote:
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ?
If 1), then this is probably our fault. If 2), then I wouldn't expect such behavior.
1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread.
Cheers, Henry
On 30 April 2013 11:24, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>wrote:
I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used...
But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts?
Just to say i have same thoughts: system should log only user's direct actions which causing changes, not every single change.
Nicolas
2013/4/30 GOUBIER Thierry <thierry.goubier@cea.fr>
I confirm, it's 1)
Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method).
I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition.
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen@veloxit.no] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote:
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ?
If 1), then this is probably our fault. If 2), then I wouldn't expect such behavior.
1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread.
Cheers, Henry
-- Best regards, Igor Stasenko.
Not so sure. Even with un-interruptible primitives, the RemoteString is wrong. It should be something like write chunk in a lock, return chunk final position once done. Then the RemoteString instance can compute the start position and store it. No more race condition for that one. An, for anything which takes a readOnlyCopy, try to flush the RW one before (or just remove that optimisation of opening multiple streams; anything which tries to do data sharing via external files is asking for trouble). Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Date d'envoi : mardi 30 avril 2013 11:24 Ã : Pharo Development Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used... But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts? Nicolas 2013/4/30 GOUBIER Thierry <thierry.goubier@cea.fr<mailto:thierry.goubier@cea.fr>> I confirm, it's 1) Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method). I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition. Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] de la part de Henrik Johansen [henrik.s.johansen@veloxit.no<mailto:henrik.s.johansen@veloxit.no>] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Objet : Re: [Pharo-project] cannot modify class comments on Linux On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote:
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ?
If 1), then this is probably our fault. If 2), then I wouldn't expect such behavior.
1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread. Cheers, Henry
On 30 Apr 2013, at 11:55, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
It should be something like write chunk in a lock, return chunk final position once done. Then the RemoteString instance can compute the start position and store it. No more race condition for that one.
Without knowing the details, I feel that it should work like that. Sven
Yes, you are right with current implementation. But if changes is not a code repository anymore, there is no need to record the position. So if we open in mode 'a' or 'a+', we could be back to an atomic primitive operation (if the primitive is blocking and can't fail/retry - which would be another option for async IO). If reading is restricted to recovery tool, the whole need for state-sharing-via-file will vanish. A readOnlyCopy/flush pair would perfectly work in this restricted case. The flush could eventually be triggered by the recovery tool itself. 2013/4/30 GOUBIER Thierry <thierry.goubier@cea.fr>
Not so sure. Even with un-interruptible primitives, the RemoteString is wrong.
It should be something like write chunk in a lock, return chunk final position once done. Then the RemoteString instance can compute the start position and store it. No more race condition for that one.
An, for anything which takes a readOnlyCopy, try to flush the RW one before (or just remove that optimisation of opening multiple streams; anything which tries to do data sharing via external files is asking for trouble).
Thierry
------------------------------ *De :* pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] *Date d'envoi :* mardi 30 avril 2013 11:24 *Ã :* Pharo Development *Objet :* Re: [Pharo-project] RE : cannot modify class comments on Linux
I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used...
But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts?
Nicolas
2013/4/30 GOUBIER Thierry <thierry.goubier@cea.fr>
I confirm, it's 1)
Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method).
I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition.
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen@veloxit.no] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote:
To be perfectly clear, does the bug occurs 1) because we open a new file descriptor for read without flushing the old one for write, 2) or does it occur with a single file descriptor opened 'rw' ?
If 1), then this is probably our fault. If 2), then I wouldn't expect such behavior.
1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread.
Cheers, Henry
On 2013-04-26, at 12:44, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
yet another reason to get rid of .changes and .sources! :)
Camillo, this is not the best reason, is it? Quand on veut tuer son chien, on l'accuse de la rage... With this kind of argumentation, I hope you won't find a bug in Integer ;) 2013/4/26 Camillo Bruni <camillobruni@gmail.com>
On 2013-04-26, at 12:44, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
yet another reason to get rid of .changes and .sources! :)
On 2013-04-26, at 20:00, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Camillo, this is not the best reason, is it? Quand on veut tuer son chien, on l'accuse de la rage... With this kind of argumentation, I hope you won't find a bug in Integer ;)
luckily we live in different universes :) your's doesn't look like mine and I am very happy with it :) PS: have fun inventing the future
My universe? Oh, you don't live in a universe of Integers? Are you in a Fractal dimension? No, no, much too Rational... Maybe you're floating then? Well, mister know-it-all, I have another sayings for you: aboyer avec les chiens The best fit for former argumentation IMO 2013/4/26 Camillo Bruni <camillobruni@gmail.com>
On 2013-04-26, at 20:00, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Camillo, this is not the best reason, is it? Quand on veut tuer son chien, on l'accuse de la rage... With this kind of argumentation, I hope you won't find a bug in Integer ;)
luckily we live in different universes :) your's doesn't look like mine
and I am very happy with it :)
PS: have fun inventing the future
On Fri, Apr 26, 2013 at 12:44:49PM +0200, Igor Stasenko wrote:
On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
The reason is in the optimalizations in the latest glibc. It really does not write the new content to the changes file immediately. We need to call flush at the end of nextChunkPut:
This is nasty one. What i worry that it affects much more than code working with .changes file.
Indeed, I expect that a bug like this would effect *anything* that involves writing to a positionable file. It's not clear to me from the discussion if this is a bug in the runtime C library, or in the gcc optimizer (sic). Is it the case that a pre-compiled VM that works properly on one Linux platform will have this bug if run on another Linux platform that has a different runtime clib? Or is it the case that a VM compiled from source on one platform behaves differently than the same VM compiled from source on a different Linux platform? Dave
Cheers, -- Pavel
On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Reproduced on Ubuntu 13.04.
Class organization remoteString filePositionHi is past the end of the changes file (i.e. exactly equal to the file size if the comment is the last operation).
Thierry ________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Pavel Krivanek [pavel.krivanek@gmail.com] Date d'envoi : jeudi 25 avril 2013 21:32 ?? : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux
Jaroslav wrote this: This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same as F17, so I guess this would be also reproducible on Ubuntu 13.04.
-- Pavel
On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
I'm on 64-bit Ubuntu 12.04
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
what architecture and distro do you use because I tried it on a 32-bit Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why the tests are not failing on CI. This error appears on all old system classes and on newely created classes too. Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376
-- Pavel
On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just try in a random class comment) Are you trying to modify a particular class comment?
2013/4/25 Pavel Krivanek <pavel.krivanek@gmail.com>
Hi,
if you will try to modify a class comment on Linux, the error "RemoteString past end of file" will appear. On windows VM it seems to work well. Can someone confirm this behavior on Linux. Squeak has the same problem.
Cheers, -- Pavel
-- Best regards, Igor Stasenko.
participants (12)
-
Camillo Bruni -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
Gisela Decuzzi -
GOUBIER Thierry -
Henrik Johansen -
Igor Stasenko -
Marcus Denker -
Nicolas Cellier -
Pavel Krivanek -
Sven Van Caekenberghe