[Vm-dev] FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche mfritsche at reauktion.de
Mon Jul 2 17:06:56 UTC 2018


Hello Alistair,

flushing the handle before truncate turns the test green indeed.

truncate does reopen (close, open) - maybe the flush should be put in
reopen? How is flushing handles handled in glue-code generally?

https://dynamic.reauktion.de/~mfritsche/ptvm.tar.zst is a kvm based vm
(hard disc, xml vm config) (user pharo, password pharo) that shows the
problem - at least on my hardware.

Best regards,

  Markus


On 02.07.2018 17:27, Alistair Grant wrote:
>  
> Hi Markus,
>
> On Mon, 2 Jul 2018 at 13:05, Markus Fritsche <mfritsche at reauktion.de> wrote:
>> interesting - below is a summary of my installation. I had this issue way back when (vm-beginners, 04/09/2014) with a complete different software setup (last time I've checked I didn't register as a bogon source on the meter, in fact, I take pride in being a clueon source at work).
>>
>> mfritsche at hawking:~/Pharo$ uname -a
>> Linux hawking 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>>
>> mfritsche at hawking:~/Pharo$ cat /proc/cpuinfo | head -n 5
>> processor    : 0
>> vendor_id    : GenuineIntel
>> cpu family    : 6
>> model        : 60
>> model name    : Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
>>
>> mfritsche at hawking:~/Pharo$ ./pharo --version
>> 5.0-201805090836  Wed May  9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM]
>> CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May  9 2018
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May  9 2018
>> VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
>> Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>> plugin path: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836 [default: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836/]
>>
>> mfritsche at hawking:~/Pharo$ ls -alh /lib/x86_64-linux-gnu/libc-2.27.so
>> -rwxr-xr-x 1 root root 2,0M Apr 16 22:14 /lib/x86_64-linux-gnu/libc-2.27.so
> I tried creating a btrfs ram disk in a docker image (I don't have the
> btrfs tools installed on my machine) and still didn't reproduce the
> problem (I do remember sqlite having problems with btrfs, and vaguely
> remember flushing and/or truncate being involved).
>
> Since you mention flushing being documented as required before
> truncating, can you try modifying the test and seeing if that makes a
> difference?
>
> FileSystemHandleTest>>testTruncate
> | out |
> out := #(1 2 3 4 5) asByteArray.
> handle at: 1 write: out startingAt: 1 count: 5.
> handle flush.
> handle truncateTo: 3.
> self assert: handle size = 3
>
>
> For the record:
>
> $ uname -a
> Linux alistair-xps13 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May
> 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
>
> $ ./pharo --version
> 5.0-201805090836  Wed May  9 08:54:40 UTC 2018 gcc 4.8 [Production
> Spur 64-bit VM]
> CoInterpreter VMMaker.oscog-eem.2380 uuid:
> c76d37e1-445c-4e34-9796-fc836dfd50c9 May  9 2018
> StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid:
> c76d37e1-445c-4e34-9796-fc836dfd50c9 May  9 2018
> VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
> Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e
> 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017
> x86_64 x86_64 x86_64 GNU/Linux
> plugin path: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836 [default:
> /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836/]
>
>
> Cheers,
> Alistair
>
>
>
>> On 02.07.2018 11:57, Alistair Grant wrote:
>>
>> Hi Markus,
>>
>> It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past.  I'm using SSDs.  I'll check again when I have access.
>>
>> Cheers,
>> Alistair
>> (on phone, thus the short reply)
>>
>> On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, <mfritsche at reauktion.de> wrote:
>>>
>>> Hi Alistair,
>>>
>>> I created a file-based ext4fs in my ram-based /tmp/ and executed the
>>> FileHandleTest starting the image out of that file system - the test
>>> still fails.
>>>
>>> Are you having your file system on rotating rust or in
>>> electron-arresting transistors (like me)?
>>>
>>>
>>> Best regards,
>>>
>>>   Markus
>>>
>>>
>>> On 02.07.2018 09:26, Alistair Grant wrote:
>>>> Hi Markus,
>>>>
>>>> The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
>>>>
>>>> Are you able to test on a file system other than btrfs?  Or anything
>>>> else that might be different in your environment?
>>>>
>>>> P.S.  I'm not saying that FilePlugin shouldn't be changed, I haven't
>>>> looked at it, but it would be nice to reproduce the issue first.
>>>>
>>>> Thanks,
>>>> Alistair




More information about the Vm-dev mailing list