Golly bugs

[Anivec]

The web version will not load my catforce output rle while the downloaded version of Golly will.

Please provide a short example of some RLE code that fails.

When I try to paste it into the web version of Golly, it simply ignores it too
Here's a fragment of the rle:

Code: Select all

x = 0, y = 0, rule = B3/S23
12$28bo99bo99bo$28b3o97b3o15b2o80b3o15b2o$31bo99bo13bobo83bo13bobo$30b2o98b2o13b2o83b2o13b2o$43b2o98b2o98b2o$42bobo97bobo5b2o90bobo5b2o$42b2o98b2o5bobo90b2o5bobo$149b2o98b2o$147b2o98b2o$146bobo97bobo$146b2o98b2o10$49bo99bo99bo$47bobo97bobo97bobo$47b3o97b3o97b3o$47bo99bo99bo3$53b2o98b2o98b2o$53b2o98b2o98b2o2$43b2o98b2o98b2o$44bo99bo99bo$43bo3b2o94bo3b2o94bo3b2o$43bobo2bo94bobo2bo94bobo2bo$42b2ob2o95b2ob2o95b2ob2o$40bo2bobo94bo2bobo94bo2bobo$40b3o4bo92b3o4bo92b3o4bo$32b2obobo8b2o84b2obobo8b2o84b2obobo8b2o$32bob2ob4o91bob2ob4o91bob2ob4o$36bo3bo95bo3bo95bo3bo$33b2o2bo95b2o2bo95b2o2bo$33bob2o96bob2o96bob2o48$2$442b2o$41b2o399bo$41bo299b2o100bo$42bo100b2o96b2o98bo98b4o$39b4o96b2o2bo97bobo99bo2bo93bo$39bo99bobobo99bo98b5o96b3o$42b3o95bo2b2o97b2ob2obo194bo2bo$42bo2bo97bo2bo98bob2o95bo100b2o$44b2o99b2o98bo97bobo$244b2o98b2o7$26bo99bo99bo99bo99bo$25bobo97bobo97bobo97bobo97bobo$26bo99bo99bo99bo99bo12$49bo99bo99bo99bo99bo$47bobo97bobo97bobo97bobo97bobo$47b3o97b3o97b3o97b3o97b3o$47bo99bo99bo99bo99bo3$53b2o98b2o98b2o98b2o98b2o$53b2o98b2o98b2o98b2o98b2o2$43b2o98b2o98b2o98b2o98b2o$44bo99bo99bo99bo99bo$43bo3b2o94bo3b2o94bo3b2o94bo3b2o94bo3b2o$43bobo2bo94bobo2bo94bobo2bo94bobo2bo94bobo2bo$42b2ob2o95b2ob2o95b2ob2o95b2ob2o95b2ob2o$40bo2bobo94bo2bobo94bo2bobo94bo2bobo94bo2bobo$40b3o4bo92b3o4bo92b3o4bo92b3o4bo92b3o4bo$32b2obobo8b2o84b2obobo8b2o84b2obobo8b2o84b2obobo8b2o84b2obobo8b2o$32bob2ob4o91bob2ob4o91bob2ob4o91bob2ob4o91bob2ob4o$36bo3bo95bo3bo95bo3bo95bo3bo95bo3bo$33b2o2bo95b2o2bo95b2o2bo95b2o2bo95b2o2bo$33bob2o96bob2o96bob2o96bob2o96bob2o48$3$41b2o98b2o98b2o98b2o98b2o$41bo99bo99bo99bo99bo$42bo99bo99bo99bo99bo$39b4o96b4o96b4o96b4o96b4o$39bo99bo99bo99bo99bo$42b3o97b3o97b3o97b3o97b3o$42bo2bo96bo2bo96bo2bo96bo2bo96bo2bo$44b2o98b2o98b2o98b2o98b2o22$49bo99bo99bo74b2o23bo99bo$47bobo74b2o21bobo97bobo74b2o21bobo97bobo$28b2o17b3o74b2o2b2o17b3o78b2o17b3o78b2o17b3o78b2o17b3o$28b2o17bo80b2o17bo76b2o2b2o17bo80b2o17bo80b2o17bo$224b2o2$53b2o98b2o98b2o98b2o71b2o25b2o$53b2o98b2o98b2o98b2o71b2o25b2o2$43b2o98b2o98b2o98b2o98b2o$44bo99bo99bo99bo99bo$43bo3b2o94bo3b2o94bo3b2o94bo3b2o94bo3b2o$

[Andrew]

When I try to paste it into the web version of Golly, it simply ignores it too

Works fine in web Golly on my Mac in Firefox and Chrome, so use a different browser or ask the author of catforce to generate nicer RLE.

[Anivec]

When I try to paste it into the web version of Golly, it simply ignores it too

Works fine in web Golly on my Mac in Firefox and Chrome, so use a different browser or ask the author of catforce to generate nicer RLE.

Oh, the RLE is much longer though, and with out any proper spacing. I believe this confuses both Golly and the Life Veiwer.

The creator of the version of Catforce I’m currently using is guaranteed not to do anything because he never reads the forums.

[LaundryPizza03]

Running this script from a beta version of EmnumPattEvo crashes Golly. I think it is not designed for Golly, but it is unclear why it crashes Golly if I attempt to run it.

filter-epe.py.txt

(2.02 KiB) Downloaded 244 times

[Andrew]

Running this script from a beta version of EmnumPattEvo crashes Golly. I think it is not designed for Golly, but it is unclear why it crashes Golly if I attempt to run it.

Golly isn't really crashing (there is no crash log). Golly is exiting because the script calls sys.exit(). Probably not a good idea to run a script that isn't meant for Golly (which should be obvious if the script doesn't import golly or glife near the start).

[Andrew]

I don't know if this is the right thread, but in the mobile version 1.3 the text is too large: ...

We're currently working on a new version of Android Golly but haven't been able to reproduce this problem on any of our devices (with Android versions ranging from 5.1 to 13), so please provide specific details about your device: Android version, screen dimensions and resolution if you know them, and if you have some sort of magnification setting enabled.

Also, in future, please report Android-specific problems in the relevant "Golly x.x for Android" thread.

[Vort]

The web version will not load my catforce output rle while the downloaded version of Golly will.

Downloaded version fails to read CatForce RLEs as well.
And right, it's a problem of CatForce, it violates RLE standard.

The creator of the version of Catforce I’m currently using is guaranteed not to do anything because he never reads the forums.

Do you mean https://github.com/mvr/CatForce ?
I was thinking about creating GitHub Issue about this problem, but for some reason Issues are disabled for this repository.
Pull Requests are enabled, so there is a chance, it should not be too hard to create fix for this problem.
It requires few lines of code probably.

[Vort]

Did anyone mentioned OS crashes when opening ~5 instances of Golly?
I often need more (because Golly have no support for tabs, like web browsers have).
Problem can be partially solved by typing "net stop uxsms" and "net start uxsms".
But sometimes OS crash leads to random programs glitching or crashing as well, which is harder to track.

I see this problem with Windows 7, did not tested with other versions, maybe they are fine.

[confocaloid]

[...] (because Golly have no support for tabs, like web browsers have) [...]

Do you know about layers? (The menu "Layer" in Golly; "Help -> Layer Menu" for more information.)

[Vort]

Do you know about layers? (The menu "Layer" in Golly; "Help -> Layer Menu" for more information.)

Didn't knew about it, thanks for the information.
However, layers feature doesn't have the same level of usability as tabs in browsers have.
Having several open Golly windows (processes) is more convenient.

[b-engine]

We're currently working on a new version of Android Golly but haven't been able to reproduce this problem on any of our devices (with Android versions ranging from 5.1 to 13), so please provide specific details about your device: Android version, screen dimensions and resolution if you know them, and if you have some sort of magnification setting enabled.

Also, in future, please report Android-specific problems in the relevant "Golly x.x for Android" thread.

Android 14, no magnification setting enabled.

[Vort]

Did anyone mentioned OS crashes when opening ~5 instances of Golly?

I figured out why crashes happen:
Because of gazillion icons created in wxBitmap** CreateIconBitmaps(const char** xpmdata, int maxstates).

There is a theoretical limit of 65,536 GDI handles per session. However, the maximum number of GDI handles that can be opened per session is usually lower, since it is affected by available memory.

[rowett]

Did anyone mentioned OS crashes when opening ~5 instances of Golly?

I figured out why crashes happen:
Because of gazillion icons created in wxBitmap** CreateIconBitmaps(const char** xpmdata, int maxstates).

There is a theoretical limit of 65,536 GDI handles per session. However, the maximum number of GDI handles that can be opened per session is usually lower, since it is affected by available memory.

I don't think that's relevant: CreateIconBitmaps is not a GDI API. Golly uses a graphical library called wxWidgets. On startup Golly only creates around 200 icons.

[Vort]

I don't think that's relevant: CreateIconBitmaps is not a GDI API. Golly uses a graphical library called wxWidgets.

CreateIconBitmaps creates GDI handles via new wxBitmap call.

On startup Golly only creates around 200 icons.

CreateIconBitmaps have "// duplicate last icon" section, which creates largest amount of GDI handles.
It is probably ok to fix this problem like this (or in similar way - with smart pointers for example, std::shared_ptr):

Code: Select all

diff --git a/gui-wx/wxalgos.cpp b/gui-wx/wxalgos.cpp
index 5f1290b1..516f93b1 100644
--- a/gui-wx/wxalgos.cpp
+++ b/gui-wx/wxalgos.cpp
@@ -590,17 +590,18 @@ wxBitmap** CreateIconBitmaps(const char** xpmdata, int maxstates)
         // initialize all pointers (not just those < maxstates)
         for (int i = 0; i < 256; i++) iconptr[i] = NULL;
         
+        wxBitmap* lastIcon = nullptr;
         for (int i = 0; i < numicons; i++) {
             wxRect rect(0, i*wd, wd, wd);
+            lastIcon = new wxBitmap(allicons.GetSubBitmap(rect));
             // add 1 to skip iconptr[0] (ie. dead state)
-            iconptr[i+1] = new wxBitmap(allicons.GetSubBitmap(rect));
+            iconptr[i+1] = lastIcon;
         }
         
         if (numicons < maxstates-1 && iconptr[numicons]) {
             // duplicate last icon
-            wxRect rect(0, (numicons-1)*wd, wd, wd);
             for (int i = numicons; i < maxstates-1; i++) {
-                iconptr[i+1] = new wxBitmap(allicons.GetSubBitmap(rect));
+                iconptr[i+1] = lastIcon;
             }
         }
     }
@@ -612,7 +613,15 @@ wxBitmap** CreateIconBitmaps(const char** xpmdata, int maxstates)
 void FreeIconBitmaps(wxBitmap** icons)
 {
     if (icons) {
-        for (int i = 0; i < 256; i++) delete icons[i];
+        for (int i = 0; i < 256; i++) {
+            wxBitmap* ptr = icons[i];
+            if (ptr == nullptr)
+                continue;
+            for (int j = i; j < 256; j++)
+                if (icons[j] == ptr)
+                    icons[j] = nullptr;
+            delete ptr;
+        }
         free(icons);
     }
 } 

[rowett]

CreateIconBitmaps creates GDI handles via new wxBitmap call.

You're correct.

CreateIconBitmaps have "// duplicate last icon" section, which creates largest amount of GDI handles.
It is probably ok to fix this problem like this (or in similar way - with smart pointers for example, std::shared_ptr)

Looks good. From my tests it reduced the GDI handles from over 5000 to 570 on startup.

GDIhandles.png (3.5 KiB) Viewed 16025 times

[Andrew]

Looks good. From my tests it reduced the GDI handles from over 5000 to 570 on startup.

Presumably Golly could also crash if 5 or more (non-cloned) layers are created. Chris, I'm unable to reproduce any crash on my Windows VM so can you please commit Vort's changes and test for any problems. I have a (very!) vague memory that sharing icon pointers caused problems, so it would be a good idea to test this change in situations like switching from a Generations rule with lots of states to a rule with fewer states and vice versa, especially via Undo/Redo. Ditto for LtL and RuleLoader rules with a different number of states.

[rowett]

Presumably Golly could also crash if 5 or more (non-cloned) layers are created. Chris, I'm unable to reproduce any crash on my Windows VM...

I can't reproduce the crash on my system. It may be because I'm on Windows 11 and the original report was on Windows 7. I merely tested the fix to see if it did reduce GDI handle usage (which it does).

On a side note using non-cloned layers doesn't seem to increase the used GDI handles so using Layers could be a workaround.

I'll do some more testing when I get time anyway.

[Vort]

I can't reproduce the crash on my system. It may be because I'm on Windows 11 and the original report was on Windows 7.

First thing, which may matter, is amount of available RAM.
Docs from Microsoft mention that handle limit is related to RAM amount.
Second thing - Aero theme in Windows 7, this is what exactly crashes.
If Aero is disabled, then there may be no crash.

Anyway, how many instances did you tried to run simultaneously?
If 65536 handle limit is still in place in Windows 11, then with 5k handles per process, there should definitely be problems with 14 processes launched.

... I have a (very!) vague memory that sharing icon pointers caused problems, ...

In case of having exact reproduction steps for problems, I will try to figure out why they happen.

On a side note using non-cloned layers doesn't seem to increase the used GDI handles so using Layers could be a workaround.

Why workarounds may be needed?

[rowett]

Anyway, how many instances did you tried to run simultaneously?
If 65536 handle limit is still in place in Windows 11, then with 5k handles per process, there should definitely be problems with 14 processes launched.

I ran 40 instances with no issues. I do have 64Gb RAM.

gollyx40.png (69.02 KiB) Viewed 15902 times

[Vort]

Here is a video demonstration of this problem, just in case:
https://www.youtube.com/watch?v=biHG0kMufA0

[Antonin Duda]

Max hash memory has been limited to 300 MB on android for a really long time, and phones are much more powerful now.

[Gustone]

Zoomed out patterns in Windows Vista look like the left, in Windows 7 it's the right. What is the cause? How do i make it look like the left in Windows 7?

[Andrew]

Zoomed out patterns in Windows Vista look like the left, in Windows 7 it's the right. What is the cause? How do i make it look like the left in Windows 7?

I suspect that on the right you have View > Smarter Scaling turned on. That option doesn't work well with sparse two-state patterns.

[eRroR_6o6]

If you try to draw a cell and reset a pattern simultaneously while it's running, it clears the whole layer. I have (by accident) learned this the hard way many, many times.

(Keep in mind I'm using golly 4.3b2, so maybe this was fixed in a newer version.)

Edit: I literally just got golly 4.3 a few minutes ago, and it still seems to have the bug.

[confocaloid]

If you try to draw a cell and reset a pattern simultaneously while it's running, it clears the whole layer. I have (by accident) learned this the hard way many, many times.

(Keep in mind I'm using golly 4.3b2, so maybe this was fixed in a newer version.)

Edit: I literally just got golly 4.3 a few minutes ago, and it still seems to have the bug.

Can you explain the details of how to reproduce the bug? I can't seem to reproduce it either in 4.3b2 or 4.3. I tried a two-state B3/S23 pattern and a History version of the same pattern. I tried drawing a cell while the pattern is evolving, and resetting a pattern. It works the expected way (the cell is drawn and then immediately dies; the pattern resets correctly).