Skip to content
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

wxWidgets Debug Alert #6

Closed
DrunkSimurgh opened this issue Aug 22, 2022 · 6 comments
Closed

wxWidgets Debug Alert #6

DrunkSimurgh opened this issue Aug 22, 2022 · 6 comments

Comments

@DrunkSimurgh
Copy link

DrunkSimurgh commented Aug 22, 2022

After the installation of the releases on Windows 10, every time that Aegisub is opened, the message in the image is encountered twice. Both installations for "Feature Release 04" and "Feature Release 05" face the same issue. Furthermore, the Portable versions work just fine. I also tested all the other major Aegisub builds for windows and none of them return this alert.
image

@arch1t3cht
Copy link
Owner

Sadly, I haven't found any way to reproduce this. It looks related to the language or locale settings, but neither changing the language of Aegisub nor the display language of Windows makes Aegisub show this message on my machine.
For what it's worth, I can tell you that this should not affect any functionality in Aegisub, so you can close the dialogs or see if the "Don't show this dialog again" option works. Let me know if you ever find a consistent way of reproducing this on arbitrary machines - I can take another look then.

I do have one more question, though - does this still happen if you delete your Aegisub config file or move it somewhere else? You said that this doesn't occur on the portable versions, and the location of the config file is the only nontrivial difference between the installed and portable versions.

@DrunkSimurgh
Copy link
Author

Thanks for your help. I'll try reproducing this.

I deleted the Aegisub config file but I still got the alert.
I uninstalled all the Aegisub builds from my machine and reinstalled this particular build but again I got this alert.
Finally, I removed the Aegisub folder from %appdata% directory and reinstalled this particular build and there was no alerts.

So, I believe the next step is to figure out which part of my old Aegisub folder in %appdata% was having conflicts with this particular build.

@DrunkSimurgh
Copy link
Author

Turns out that if a script which relies on utf8 library is present, this alert shows up in this particular build of Aegisub.

@arch1t3cht
Copy link
Owner

Ah - I could reproduce it now, and somehow it seems to have been introduced by merging wangqr's "Time to video" feature of all things. I'll take a closer look soon.

@arch1t3cht
Copy link
Owner

So I found out two things:

  • Judging by the error message, in principle this seems to be an issue in the utf8 library. It's called by an os.setlocale call in primitives/native.lua which breaks the invariant which the assertion is testing. For the future, you could try commenting out that call and see if that breaks anything.
  • However, I did also finally find out what caused these assertion errors to pop up now and not before. It appears that this is triggered by the new icons button_align_X.png added with wangqr's "Time to video" feature. I couldn't find out which precise property it was, but some piece of metadata in these imaged differed from the other icon files, which seems to have triggered the function running the assertions. Reexporting any arbitrary icon file using GIMP with default settings triggered this error for me. Reexporting them with ffmpeg instead makes it stop.

So I sent all the new icon files through ffmpeg once and rebuilt, and the assertion errors stopped.
With this, the error messages should be gone in the next build. But from what I've gathered this is still only a workaround and not a fix, with the real issue being the setlocale call in the utf8 library clashing with Aegisub's settings in some way. So maybe you can also see if taking these calls out will break any of your use cases.

@DrunkSimurgh
Copy link
Author

Thank you very much for your help. The problematic code seems to be os.setlocale(utf8.config.locale or "english_us.65001", "ctype"). I commented this line and everything seems to be working fine. As an alternative I also replaced it with os.setlocale(utf8.config.locale or "english_us.cp65001", "ctype") and this also seems to be working fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants