-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Zinc] Infinite recursion on UTF encoding error #17542
Comments
That is the classic 'error while printing an error' situation. Quite annoying indeed. One thing that might help is the recently added 55296 asCharacter asString encodeWith: #utf8lossy it was originally added to read any byte sequence without erroring, Anyway that is the current behaviour. Not sure it is helpful. |
It might be also a clear sign that debuggers should not use printString but something error related that could return a safer variant |
I'm looking into fixing this issue at the root. I think the solution is for the logger, created in
I'll submit a PR here first. |
If it modifies Zn* classes I need to know about it, at least. I am curious to what you want to do. Instead of |
So I looked into what the actual implementation of a
So now I'm hesitating whether it's worth making a new class just for encoding during error logging, with the single method The problem occurs during pharo/src/Kernel-CodeModel/Context.class.st Lines 1361 to 1364 in aa1029e
Catching ZnUTF8InvalidEncoding (or Exception to be safe) and using the default 'error during printing' would be the simplest thing to do.Otherwise, I guess we could replace invalid UTF characters with their U+XXXX strings and try again, with a final guard to finally give up for good measure.
|
In the feenk fork of zinc [ https://github.com/feenkcom/zinc ] in the last two commits I did some refactoring and added an experimental Here is how it works: testDebuggingUTF8
self
assert: (({ $A. 55296 asCharacter . $B } as: String) encodeWith: #utf8debug) utf8Decoded
equals: 'A<Cannot utf-8 encode code point 55296>B' Not sure how to plug it in though. |
Can you elaborate about why there is a fork for feenk? Especially for zinc I don't see a reason why this is necessary. Does it mean pharo will become a second class child of support? |
Forks are a standard way to collaborate in the git (hub) world. They offer a temporary divergence that can be relatively easily consolidated later on. This has nothing to do with forking as in going separate ways. The feenk Zinc fork is a synced fork: it is updated regularly in both directions. I would prefer this to be the same with Pharo as it is very hard to keep things in sync right now. |
I did an experiment in Pharo 12. I loaded the new code from Zinc upstream to get the ZnDebuggingUTF8Encoder. Then I changed two methods by switching from the 'utf8' to the 'utf8debug' encoder:
When I execute the offending code,
As you can see both the character and string are printed as <Cannot utf-8 encode code point 55296> |
Nice, this gets rid of the infinite recursion. |
Bug description
PharoDebug.log
file.ZnInvalidUTF8
exception that causes the loops).To reproduce
Minimal example that triggers the infinite recursion:
55296 asCharacter asString utf8Encoded
Expected behavior
The error logging should not be susceptible to the encoding error it is trying to log.
Additional context
Click here to show/hide the cropped top of the stack.
The text was updated successfully, but these errors were encountered: