Smalltalk › Squeak › Squeak - Dev

[BUG] MultiByteFileStream(Object)>>error: primGetPosition: failed

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Christoph Thiede

[BUG] MultiByteFileStream(Object)>>error: primGetPosition: failed

Hi all, I don't know if someone of you saw this error message recently?

MultiByteFileStream(Object)>>error: primGetPosition: failed

(Just for the case this should be a VM-related problem, I'm using OpenSmalltalk 201912311458 on Win 1903.)

I experienced it various times, and each time, once the error had occurred once, no more access to the sources file was possible. I could neither select any message then nor debug, even quitting the image without saving was not possible; each attempt raised the same error again.

Now I finally discovered a scenario to reproduce this issue:

(Disclaimer: This might crash your image! Save *before* doing this!)

Debug the following, step over #unload, and during then loading happens, interrupt the process via cmd-dot:

Please note that you will probably only have one chance to reproduce it, because the package will be cached.

If you now open a browser, for example, selecting any message will raise the #primGetPosition: failure.

However, if you continue from the interrupt, your image won't suffer consequential damages.

This is a real problem because especially on slower images, various tests can fail and damage your image because of their timeout limits.

In a fresh (!) Trunk image, I could reproduce this several times by running MCPackageTest or MCFileInTest.

Increasing their timeouts would be a dirty workaround for the moment.

I also experienced the same problem in other projects where related MC operations were run in a timeout-limited context.

So, how can we fix it?

I assume that it is problematic if the file pointer does not get closed correctly.

Would you consider a critical block an appropriate solution to fix the issue?

But how would you write one the best way (never faced that stuff before), and doesn't this have undesirable disadvantages such as restricted debugging possibilities?

Questions over questions :-) Any help or response will be appreciated!

Best,

Christoph

Carpe Squeak!

Christoph Thiede

UserInterruptException (was: [BUG] MultiByteFileStream(Object)>>error: primGetPosition: failed)

System-ct.1136 should fix the original issue. However, interrupting this operation via cmd+dot still leads to failures. Do we want to fix this?

Once I stumbled about some comment in Squeak that expressed the wish to have a UserInterruptException. Spoken generally, is this wish consensus and still up to date?

One could argue that is is not useful to debug a method in a state at which a big part of usual Squeak features is disabled. In the given example, you cannot even expand the debugger without dealing with decompiler errors raised by Shout.

One could also argue that each time we catch a UserInterruptException (though this should be really few occurrences) to prevent the handled code being interrupted we also disable advanced users to explore the details of this behavior interactively.

The original example that proposed the UserInterruptException was Debugger >> runUntil. In this example, UserInterruptException could be used to hide the bytecode implementation against the inexperienced user.

Maybe the usage of such a UserInterruptException could be stuff for another preference?

Looking forward to your opinions!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 5. Februar 2020 13:18 Uhr
An: Squeak Dev
Betreff: [squeak-dev] [BUG] MultiByteFileStream(Object)>>error: primGetPosition: failed

Hi all, I don't know if someone of you saw this error message recently?

MultiByteFileStream(Object)>>error: primGetPosition: failed

(Just for the case this should be a VM-related problem, I'm using OpenSmalltalk 201912311458 on Win 1903.)

Now I finally discovered a scenario to reproduce this issue:

(Disclaimer: This might crash your image! Save *before* doing this!)

Debug the following, step over #unload, and during then loading happens, interrupt the process via cmd-dot:

Please note that you will probably only have one chance to reproduce it, because the package will be cached.

If you now open a browser, for example, selecting any message will raise the #primGetPosition: failure.

However, if you continue from the interrupt, your image won't suffer consequential damages.

This is a real problem because especially on slower images, various tests can fail and damage your image because of their timeout limits.

In a fresh (!) Trunk image, I could reproduce this several times by running MCPackageTest or MCFileInTest.

Increasing their timeouts would be a dirty workaround for the moment.

I also experienced the same problem in other projects where related MC operations were run in a timeout-limited context.

So, how can we fix it?

I assume that it is problematic if the file pointer does not get closed correctly.

Would you consider a critical block an appropriate solution to fix the issue?

But how would you write one the best way (never faced that stuff before), and doesn't this have undesirable disadvantages such as restricted debugging possibilities?

Questions over questions :-) Any help or response will be appreciated!

Best,

Christoph

Carpe Squeak!