Really specific bug on Windows 8.1

Has something gone haywire? Let us know about it!
Post Reply
User avatar
Scorbie
Posts: 1692
Joined: December 7th, 2013, 1:05 am

Really specific bug on Windows 8.1

Post by Scorbie » April 20th, 2015, 1:31 pm

I'm not sure if this is actually a bug or an Easter Egg congratulating sawtooth 201.
This is the only pattern that shows the bug.

How to reproduct the bug:

1. Paste THIS pattern on Golly (Congrats again to Kazyan, dvgrn, and calcyman):

Code: Select all

#C slightly smaller pop-201 sawtooth
#C Population = 201 at T=0, 1840, 88320, 4152880, 195187200, 9173800240,
#C  431168613120, etc.
#C  -- asymptotically approaching (from above) an expansion factor of 47
x = 55, y = 79, rule = B3/S23
49b2o$49b2o2$23b2o5b2o$23b2o5b2o5$43bo5bo$42b3o3b3o$41b2obo3bob2o3$23b
o7bo12bo3bo$22bo2bo3bo2bo11bo3bo$26bobo$26bobo$26bobo$22bo2bo3bo2bo$
23b3o3b3o7$43bo$43bobo$43b2o$30b2o$30b2o2$10b2o$8b2ob2o8bobo$8bo2bo10b
o$8bo2bo$9b2o33b2obo3bob2o$32bo11bo2bo3bo2bo$9b2o20bo13b3o3b3o$8bo2bo
19b3o$2o6bo2bo$2o6b2ob2o$10b2o9bobo$21b2o$22bo2$45b2o$45b2o2$20bo$20bo
bo$20b2o2$25b2o$25b2o$6b4o15b2o$4b2o4b2o13bo$4b2o5bo12bobo$6b2obobo12b
ob2o$11bo$7bo3bo$7bo4bo12b2o$9b3o3bo9b2o$9b2o4bo$15b2o$17bo$17b3o3$20b
o$19bob5o$18b2o5bo$18b2o3bo2bo$26bo$20b2obo2bo$23bo2bo$24b2o$24b2o!
[[ AUTOSTART ZOOM 3 STEP 4 ]]
2. Carefully cut any region of the pattern (and optionally paste it somewhere else).
3. Run the pattern and press 'z'

If you followed all the steps correctly, you would be able to see the easteregg saying that the sawtooth 201 is something more than to be understood by a simple algorithm. It's a wonder.

User avatar
biggiemac
Posts: 515
Joined: September 17th, 2014, 12:21 am
Location: California, USA

Re: Really specific bug on Windows 8.1

Post by biggiemac » April 20th, 2015, 5:46 pm

Happens on Windows 7 as well. It only happens if I open it using Ctrl-Shift-O, and do a cut-and-paste-elsewhere before running anything. Then running and pressing z brings a "File could not be loaded by any algorithm" error. Could it be the comments before the .rle?

Edit: Actually, it happens when pasting patterns that have their viewer comments at the bottom of the rle. For example, I just lifted this shamelessly off the hershel conduits thread and it has the same behavior. I bet it's because the end tags aren't escaped by a "#" character. I wonder why pasting it works in the first place?

Code: Select all

x = 172, y = 153, rule = B3/S23
42b2o11bo$42b2o10bobo$54bobo2b2o3bo$53b2ob2o2bo2bobo$57bobo3bobo$53b2o
bo2b4obo$53b2obobo3bo$57bobo3bo$58bobo3bo$59bo3b2o$78bo$76b3o$3b2o70bo
9bo$4bo45b2o23b2o6b3o$2bo47b2o30bo$2b5o14b2o12b2o45b2o$7bo13bo12bo2bo
48b2o$4b3o12bobo11bob2o49bo$3bo15b2o12bo50bobo$3b4o25b2o50b2o$b2o3bo3b
2o35b2o$o2b3o4b2o35bo$2obo44b3o$3bo46bo11b2o23bo$3b2o58bo22bobo$60b3o
8b2o14bo$60bo11bo$11b2o56b3o$12bo56bo$9b3o$9bo5bo$15b3o$18bo$17b2o15b
2o$34b2o40b2o28bo$77bo26b3o$62bo11b3o26bo$60b3o11bo28b2o$59bo$59b2o$
65b2o44b2o$24b2o39b2o7bo37bo$23bo2bo45b3o37bob2o$23bobo45bo32b2o4b3o2b
o$24bo46b2o31b2o3bo3b2o$109b4o$79b2o14b2o15bo$79bo10b2o2bobo12b3o$77bo
bo11bo2bo13bo$77b2o10bo2b3o14b5o$89b3o21bo$92bo18bo$91b2o18b2o$106b2o$
106bo$103b2obo$102bo2bo$103b2o$88b2o$55b2o31b2o$55bo$56b3o6b2o$58bo2b
2o2b2o$58bobobo12b2o3bo$57b2obo14bo3bobo$57bo2bo15bo3bobo$58b2o17bo3bo
bob2o$75bob4o2bob2o$74bobo3bobo$74bobo2bo2b2ob2o$75bo3b2o2bobo$83bobo
10b2o$84bo11b2o3$98b2o11bo$98b2o10bobo$110bobo2b2o3bo$109b2ob2o2bo2bob
o$113bobo3bobo$109b2obo2b4obo$109b2obobo3bo$113bobo3bo$114bobo3bo$115b
o3b2o$134bo$132b3o$131bo9bo$106b2o23b2o6b3o$106b2o30bo$91b2o45b2o$90bo
2bo48b2o$89bob2o49bo$89bo50bobo$88b2o50b2o$103b2o$103bo$104b3o$106bo
11b2o23bo$119bo22bobo$116b3o8b2o14bo$116bo11bo$125b3o$125bo2$71bo$71b
3o$74bo$73b2o15b2o$90b2o40b2o28bo$133bo26b3o$118bo11b3o26bo$116b3o11bo
28b2o$115bo$115b2o$121b2o44b2o$80b2o39b2o7bo37bo$79bo2bo45b3o37bob2o$
79bobo45bo32b2o4b3o2bo$80bo46b2o31b2o3bo3b2o$165b4o$135b2o14b2o15bo$
135bo10b2o2bobo12b3o$133bobo11bo2bo13bo$133b2o10bo2b3o14b5o$145b3o21bo
$148bo18bo$147b2o18b2o$162b2o$162bo$159b2obo$158bo2bo$159b2o$144b2o$
111b2o31b2o$111bo$112b3o6b2o$114bo2b2o2b2o$114bobobo12b2o3bo$95b3o15b
2obo14bo3bobo$95bo17bo2bo15bo3bobo$96bo17b2o17bo3bobob2o$131bob4o2bob
2o$130bobo3bobo$130bobo2bo2b2ob2o$131bo3b2o2bobo$139bobo10b2o$140bo11b
2o3$108bo$107b2o$107bobo!
[[ AUTOSTART STEP 8 ]]
Physics: sophistication from simplicity.

User avatar
Scorbie
Posts: 1692
Joined: December 7th, 2013, 1:05 am

Re: Really specific bug on Windows 8.1

Post by Scorbie » April 20th, 2015, 7:08 pm

biggiemac wrote: I wonder why pasting it works in the first place?
AFAIK, Golly ignores everything after the ! Character in the rle. But then why does it make unexpected behavior in this case?

User avatar
Andrew
Moderator
Posts: 942
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Really specific bug on Windows 8.1

Post by Andrew » April 20th, 2015, 8:28 pm

Thanks for the reports. I can reproduce the bug on my Mac so it should be easy to fix. Not sure where the problem is at the moment -- possibly in the code that saves/reads .mc files. Note that the bug only happens when using HashLife (or RuleLoader) and never in QuickLife. When using QuickLife, Golly saves temporary pattern files (for use by Undo/Redo) in RLE format, so that code seems to be working fine. In all the other algos, temporary pattern files are saved in macrocell format, so I'm guessing that the "[[..." stuff in the initial RLE data is somehow ending up in the temporary .mc file created when you run the pattern. But very odd that it only happens after a paste. (Dave, if you're watching, I'm hoping this might help solve your long-standing undo related bug, so stay tuned.)

In the meantime, best to avoid putting viewer tags after RLE data (but probably a bit late for that!).

EDIT: Or else prefix all lines after ! with #C, like this:

Code: Select all

#C slightly smaller pop-201 sawtooth
#C Population = 201 at T=0, 1840, 88320, 4152880, 195187200, 9173800240,
#C  431168613120, etc.
#C  -- asymptotically approaching (from above) an expansion factor of 47
x = 55, y = 79, rule = B3/S23
49b2o$49b2o2$23b2o5b2o$23b2o5b2o5$43bo5bo$42b3o3b3o$41b2obo3bob2o3$23b
o7bo12bo3bo$22bo2bo3bo2bo11bo3bo$26bobo$26bobo$26bobo$22bo2bo3bo2bo$
23b3o3b3o7$43bo$43bobo$43b2o$30b2o$30b2o2$10b2o$8b2ob2o8bobo$8bo2bo10b
o$8bo2bo$9b2o33b2obo3bob2o$32bo11bo2bo3bo2bo$9b2o20bo13b3o3b3o$8bo2bo
19b3o$2o6bo2bo$2o6b2ob2o$10b2o9bobo$21b2o$22bo2$45b2o$45b2o2$20bo$20bo
bo$20b2o2$25b2o$25b2o$6b4o15b2o$4b2o4b2o13bo$4b2o5bo12bobo$6b2obobo12b
ob2o$11bo$7bo3bo$7bo4bo12b2o$9b3o3bo9b2o$9b2o4bo$15b2o$17bo$17b3o3$20b
o$19bob5o$18b2o5bo$18b2o3bo2bo$26bo$20b2obo2bo$23bo2bo$24b2o$24b2o!
#C [[ AUTOSTART ZOOM 3 STEP 4 ]]
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
dvgrn
Moderator
Posts: 10714
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Really specific bug on Windows 8.1

Post by dvgrn » April 20th, 2015, 10:02 pm

Andrew wrote:(Dave, if you're watching, I'm hoping this might help solve your long-standing undo related bug, so stay tuned.)
Actually, I was thinking that you might have checked in a fix for this bug almost a year ago now. That would mean that it's fixed in the Golly 2.7b2 beta (I think).

The message I sent to golly-test certainly seems to describe the same basic symptom, with comments having something to do with the problem, and a Ctrl+Z being the key trigger...?

User avatar
Andrew
Moderator
Posts: 942
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Really specific bug on Windows 8.1

Post by Andrew » April 21st, 2015, 3:25 am

dvgrn wrote:Actually, I was thinking that you might have checked in a fix for this bug almost a year ago now. That would mean that it's fixed in the Golly 2.7b2 beta (I think).
The long-standing undo bug I was thinking of was the one that causes cells to appear in the wrong place. (Are you saying you think that's fixed? If so I don't remember doing anything to fix it.) But that bug is not related to the one reported above -- I've now fixed that. Turns out it was due to RLE comments getting incorrectly copied into the macrocell file. And not just comments after the "!" -- if the RLE header had a comment like "#Rhubarb" then the same sort of error would occur (this time complaining about an unknown rule "hubarb").
dvgrn wrote:The message I sent to golly-test certainly seems to describe the same basic symptom, with comments having something to do with the problem, and a Ctrl+Z being the key trigger...?
The error message looks identical, but the pattern listed in your email doesn't have any problem comments, so it doesn't seem to be the same bug. I couldn't reproduce it (before making the comment fix). If you can build Golly you might want to pull my latest changes and see if that error still occurs. I've added the full path to the "File could not be loaded" dialog so it's easier to open the offending file and see what's gone wrong.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Scorbie
Posts: 1692
Joined: December 7th, 2013, 1:05 am

Re: Really specific bug on Windows 8.1

Post by Scorbie » April 28th, 2015, 6:32 am

Another one:
Go to this post: viewtopic.php?f=2&t=1599&start=175#p19077
Copy the code box and open in Golly with ctrl shift o.
Select the lowermost-leftmost conduit (a C to C) appropriately and press s to shrink the selection.
I think this bug happens because y=256 is in the selection

User avatar
Andrew
Moderator
Posts: 942
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Really specific bug on Windows 8.1

Post by Andrew » April 28th, 2015, 10:41 am

I don't see any problem with the shrunken selection, so what exactly is the bug? Maybe post a screen dump.

And I don't understand the statement "y=256 is in the selection" -- the bottom most live cell in the final selection is at y=247.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Scorbie
Posts: 1692
Joined: December 7th, 2013, 1:05 am

Re: Really specific bug on Windows 8.1

Post by Scorbie » April 28th, 2015, 11:41 am

Andrew wrote:I don't see any problem with the shrunken selection, so what exactly is the bug? Maybe post a screen dump.
Next time when I write a bug report, I'll try to elaborate as much as possible. Sorry about that.
The bug occurred 2~3 times just before, but I can't reproduce it now. Strange.
The symptom was that the selection was in the wrong place, something like this:
Andrew wrote:And I don't understand the statement "y=256 is in the selection" -- the bottom most live cell in the final selection is at y=247.
I meant that "The bug might be happening because the user selected a region including y=256"
I'll add more details in this post when I get to reproduce the bug.
Attachments
The bug "looked" like this. This is just a picture describing the bug, not the picture of a bug itself.
The bug "looked" like this. This is just a picture describing the bug, not the picture of a bug itself.
something.png (5.11 KiB) Viewed 9042 times

User avatar
Andrew
Moderator
Posts: 942
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Really specific bug on Windows 8.1

Post by Andrew » April 28th, 2015, 6:45 pm

Maybe you typed "s" before releasing the mouse button? That's the most likely explanation. Less likely is that Golly is seeing events in the wrong order if you hit "s" very soon after releasing the mouse button. I have had occasional reports of weird bugs on Windows that only make sense if Golly has either seen events in the wrong order or some events (particularly mouse-up events) have gone missing.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Scorbie
Posts: 1692
Joined: December 7th, 2013, 1:05 am

Re: Really specific bug on Windows 8.1

Post by Scorbie » May 1st, 2015, 6:36 am

@Andrew Sorry for the late reply. I think what you said was right. I was using a touchpad, so I must have clicked s before I took my hand off the touchpad.

Post Reply