App crashes on Windows when backgrounded about shoes-deprecated

[Phrogz]

Possibly a duplicate of issue #142, though that issue claims that foregrounding is relevant. In my experience the app goes down on its own 95% of the time while in the background. (There were a handful of cases in 8 hours of interactive editing and launching where I was able to background it, make some changes, and then foreground it again without it crashing. Perhaps this was simply because I did so quickly enough, though I don't think so.)

[ccoupe]

Sigh. This is going to be a tough one to fix - I don't have the Windows skills to debug that. The best guess is a mismatch between Gtk threads (pthreads emulation), Ruby threads and the unlying Windows threading.

[Phrogz]

Wow. My sympathies. (That's all I can offer, as I too have no expertise in that area.)

[IanTrudel]

I am having the same problem on Windows 8.1 using Shoes 3.2.15.

[D1353L]

Will you fix it? If yes, when? It is important for me because I must know: should I rewrite my project on other GUI framework or not.
I like Shoes and I want use it.

[ccoupe]

No one can promise to fix anything or give you a time frame. If it was easy it would have been fixed years ago.

[IanTrudel]

It would be helpful if anyone who has investigated the issue shares his or her findings. We might be able to figure something out of the findings.

[ccoupe]

It would be helpful to know why Windows thinks it's hung - What event is it not responding to. I don't know the Windows event system well enough or the tools. I haven't found a log that shows anything I understand. Maybe the App is running 100% cpu? Or 0% These would be helpful data points.

[IanTrudel]

ccoupe, the CPU usage is the same as a normally running shoes. My app is more responsive and freeze considerably less since having the code handling events all in one place, no duplicate/multiple events on stacks and no overlay clickable regions. It will however hang when the app is in the background for a period of time (few to several minutes instead of relatively immediately).

[ccoupe]

Thanks, that helps a bit. If that is the cpu used by Shoes when Windows reports a hang then I really need to find a tool that reports on all threads of a running app. I vaguely recall there is such a thing.

The event handling I'm worried about isn't Shoes, it's lower down in gtk, and windows.
--Cecil

[ccoupe]

Here's a description of what's happening from Windows perspective. http://msdn.microsoft.com/en-us/library/windows/desktop/dd744765%28v=vs.85%29.aspx

I'm not signing up of their service so that option is closed.

[ccoupe]

Hmm. According to the perfmon tool (search for it, you probably have it). A shoes app doing nothing, just sitting there (splash screen, manual, my little app) runs 100% That's before it hangs. Can anybody confirm? If true, it's really bad.

[IanTrudel]

Good news, Cecil. I figured out a way to consistently cause this issue while giving us more insight into it. Below you shall find a pair of smelly Shoes, handle with care.

How to cause the issue:

1. Open Task Manager
2. Run HangOn.rb with Shoes
3. Select other windows to be on foreground, try to have a bit of the HangOn.rb window visible in order to see whether the animation is going on or not.
4. Check Shoes in Process pane in Task Manager
5. Hold CTRL + ALT for a while, release.
6. You are now the proud owner of a Not Responding pair of Shoes.

Interesting insight: HangOn.rb keeps logging timestamps in a file even when it is not responding.

HangOn.rb

Shoes.app(width: 1200, height: 325, title: "Hang on, shoes!") do
   @para = []
   @log = File.open("#{Time.now.strftime("%H%M%S")}.log", "w")
   15.times.each { |n|
      @s = stack(width: 1200, height: 325, top: 0, left: 0) do
         start do
            @para << para("Burning shoes!")
            animate(rand(5) + 1) { 
               @para.each { |m| 
                  m.style(size: rand(50), stroke: "#" + rand(15).to_s(16) + rand(15).to_s(16) + rand(15).to_s(16))
               }
               if 0 == n
                  @log.puts(Time.now.strftime("%H%M%S"))
                  @log.flush
               end
            }
         end
         #click { 500000.times { |i| i + rand(i) } }
      end
   }
   @s.click { @para.each { |n| n.text = n.text.reverse } }
end

[ccoupe]

I haven't checked your hangon.rb code yet but you're comment about the logging continuing says something very important. Ruby is not hung and much of Shoes is not hung. My observation of 100% at idle suggests that the gui thread (gtk2 isn't behaving) properly. It certainly gives me a place to see if there is a silly error on my part.

[IanTrudel]

This is also my observation. Process Explorer reports that both shoes.exe and msvcrt-ruby210.dll are running while the GUI is not responding. There are no distinguishable difference on CPU usage or cycles delta between a fully working Shoes app and a not responding one. See below (screenshot while HangOn.rb is not responding). Let me know if I can be of further assistance.

[ccoupe]

Thanks so much. Process Explorer is what I was looking for. The stack button gets me very close to
where the race condition is. At first glance, their may be confusion between Ruby and Gtk (cause by me and Shoes) on clocks and time.

[ccoupe]

I think I know where the problem lies (it's in Shoes calling a deprecated Ruby internal function). It's blind luck that it runs in Linux. Too soon to say what the fix is or how long it will take to fix. Thanks for your perseverance and support.

[IanTrudel]

You're welcome, Cecil. It seems that fixing this issue will make a lot of people happy, myself included. Once again let me know if you need further assistance.

[ccoupe]

For those willing to test, I've uploaded a Shoes 3.2.16 with some changes that (so far) don't hang on Windows. It still runs 100% cpu (one core) at idle so my task is not finished.

http://shoes.mvmanila.com/public//public/shoes/beta/shoes-3.2.16-gtk2-32.exe

Please do not use the Shoes packaging features with this beta.

Woops -don't bother.

[IanTrudel]

The correct link is http://shoes.mvmanila.com/public/shoes/beta/shoes-3.2.16-gtk2-32.exe

This version will still hang using the method I described earlier, holding CTRL+ALT for a while. It also takes one core around 90-100% at idle running shoes manual.

Do you need stack traces on shoes.exe, msvcrt-ruby210.dll, etc?

[ccoupe]

Don't tell anyone, but there is a Shoes-3.2.16-msw-32.exe you could download. Subtle differences in the name. It doesn't use Gtk, It's more like Shoes 3.1 at the C level and is more likely to exhibit additional bugs. The hang may be more frequent with it -- it's been a problem since 3.0

[IanTrudel]

I gave the msw version a try for good measure. It doesn't hang by holding CTRL+ALT for a while. Loading is slower than the gtk2 version but it is noticeably faster animating HangOn.rb and no core used at 100%. The msw overall performances is however decreasing using my application, more complex, when the number of images are increasing (noticeable at 40 and sluggish at 60+ images) whereas the gtk2 version slightly noticeable at 50.

[ccoupe]

There's a memory leak in Shoe animation (all platforms). Watch the splash screen suck memory 4KB/min or faster. Depending on your app, that might matter. Might not. Supposedly, gtk2/windows has a optional theming engine which is not included with Shoes. I think it's bit ugly on Windows but I never intended to support Windows with 3.2 until it just happened to cross compile and kind of work.

The original problem still exists.

[ccoupe]

Status update: I'm still working on the problem(s) with help from Backorder. It's not pretty being this deep in the swamp. You should not expect a quick answer. Sorry.

[ccoupe]

For the bold (or desperate): I think I've fixed the problem. It works for me which might be different than works for you, so it needs some testing. http://shoes.mvmanila.com/public/shoes/beta/shoes-3.2.16-gtk2-32.exe

I'll hunt you down and taunt you if you complain about the new packaging features in this issue thread or complain that the beta spawns a console window and its 8MB larger. It's a beta! And it needs testing.

[D1353L]

Seems like issue was fixed. Now it works fine!