UI::Notification causes a bugsplat in 2019

Developers Ruby API
1

I know it would help if I create a small example to reproduce the error, but for now this explanation should do:
I use a timer that waits a couple of seconds to then perform a http-request using Sketchup::Http::Request in order to check if a new version of the extension is available. If that is the case I create a UI::Notification to inform the user that a new version is available and ask him/her if he/she wishes to update. Both a click on accept or on dismiss cause a bugsplat in SketchUp 2019. The same code causes no trouble in SketchUp 2018 nor 2017.

I have sent a bugsplat report.
Anyone else having troubles with UI::Notification in 2019?
Could someone from the SketchUp team perhaps take a look at the bugsplat report? It contains my name and the same description as mentioned here.

2

What platform? (Useful for looking up bugsplats as they separated. Also, this is UI code for there is different implementation per platform.)

Which version of SketchUp 2019 are you using?

3

I think I found it - we’re crashing somewhere in Ruby when we try to invoke the callback. I’m not sure why, there isn’t much to go my from the BugSplat.

Can you provide a repo example?

4

Just FYI, it has always been a “no go” to create GUI windows inside a timer block.

If you try with message boxes, there is a runaway with multiple message boxes being created until the user must use Task Manager to kill the SketchUp process.

P.S. - I thought we had discussed this (extension check) in a previous thread and advised you to use the AppObserver ?

EDIT - Okay, it wasn’t you, but you were a participant in both recent topic threads where TIG and I suggested using the AppObserver …

5

19.1.174 on windows. Now, I cannot remember having troubles on 2019 before with this. Not sure when I updated though.

On OSx with 19.0.6884 I am not having any issues.
I will try to distill a repo example when I can.

I know. But, I am not creating the gui component in the timer, but rather in the async callback of Sketchup::Http::Request (which in return is created in the timer however).

:slight_smile: yes. II am not sure if it really is related to the timer. I might need to refactor that part indeed :slight_smile:

6

Laff! Really? In the call chain of the block is still within the block.

I just tried SketchUp 19.2 and no BugSplat! with either of these …

UI.start_timer(3,false) {
  Sketchup::Http::Request.new("http://localhost:8080").start { |req, res|
    UI.messagebox("BugSplat! Me baby!")
  }
}

UI.start_timer(3,false) {
  note = UI::Notification.new(Sketchup.extensions[0],"BugSplat! Me baby!")
  note.on_accept("Accept") do |notification, title|
    puts "The user pressed [#{title}] with message #{notification.message}"
  end
  note.on_dismiss("Dismiss") do |notification, title|
    puts "The user pressed [#{title}] with message #{notification.message}"
  end
  Sketchup::Http::Request.new("http://localhost:8080").start { |req, res|
    note.show
  }
}
7

That’s only with modal dialogs.

Can you try with latest released version 19.2?

8

I just did with the code above, and no BugSplat! on my machine (Win10 - r1809).

Weirdly no runaway or BugSplat! when a modal messagebox is within a Http request block.

9

Glad I made you smile.

I will try su 19.2 in a few minutes and update if that helps.

10

Wow … even …

UI.start_timer(3,false) {
  UI.messagebox("BugSplat! Me baby!")
}

… no longer causes a uncontrolled runaway. It’s been fixed. Woo hoo!

11

This is not causing a bugsplat either on my machine. (v19.1.174). Also, when I create a small example => No bugsplat. There must be something else causing this.

12

Hmm, 19.2.222 also bugsplatted on me. Posted the bugsplat report.
I will distill all code related to the UI::Notification and create a repo for it.

13

And… the minimal example I can make of it… well… refuses to splat :upside_down_face:
@tt_su let’s perhaps have a short look at it on devcamp? For now I fail to create a smaller example that reproduces the issue.

14

Got it.
I was using UI.stop_timer(timer_id) as a first call in the timer. As soon as I removed that line I got no more bugsplats.
I remember at some point it was recommended to first stop the timer, has that changed?

15

Only if the second parameter (repeat) is true and the evaluation of the block would take longer than that of the interval. If the timer will not repeat there’s no point in stoping the timer as it’s basically already stopped (or ready to stop.)

16

I see where I got this from:

 # Opening a modal window will cause this non-repeating timer to repeat.
      # to work around this we explicitly stop it, just to be safe.
      #UI.stop_timer(timer_id)
      # (!) Calling UI.stop_timer appear to make SketchUp prone to crashing so
      #     we will instead keep this variable instead to prevent triggering
      #     the event multiple times.

At some point in time it was recommended to stop a timer even though it was a nonrepeating one. But, as the comments say, that can cause crashes. And I believe it are those crashes I am (was) experiencing.

17

Yea, the issue is only with non-repeat-timers, because the timer was being stopped after triggering the callback. But if the callback is blocking (modal dialog) the timer would repeat.

Hmm, I wonder when that happened… interesting.

Ah, I’m guessing that UI.stop_timer is deleting the timer and thus causing an access violation.
Can you log that in the issue tracker?

I might have run into the same issue as you a long time ago because I’ve been copy+pasting this pattern in my extensions: