Anything to be done about hangs?

BTW, this morning’s hang(s) is without Live being open.

Did you have WLAN enabled but no working Internet Connection?
In the past for example NI plugins which wanted to send user data did face this issue which caused hangs.

There is a wireless network in my house, if that is the question.

Internet connection seems fine this morning (and yesterday).

You keep reporting hangs but you have yet to answer some basic questions we asked such as

  1. When did this start happening?
  2. What changed at the point this started happening? For example,
    • Did you add new code or some GP Script that is stuck in a loop?
    • Another plugin that you hadn’t used before that may be hanging
    • More rackspaces?
    • Windows or A/V update
    • Are you running out of memory? Is your swap space configured properly?

There’s no magic. Something changed and you need to focus on figuring out what that might be.

Without basic information like that, everything else you’re doing here (and telling us about) is just not helpful in beginning to diagnose the problem. You’re throwing atom bombs (Analyze, WinDbg) at the problem instead of trying to come up with a hypothesis that you can then test.

A simple Google search for RubberBandStretcher would have given you the answer to that.

Maybe, if you would have a shortcut in the documents folder and GP touches that folder, it could be enough.

To see if there’s network traffic going on to a non-existent or no longer existent NAS, you could try netstat -an 1 | find "SYN" which would reveal connections that are being tried but haven’t succeeded yet, or netstat -an 1 | find ":445" which would reveal all smb/samba traffic

The presumption here is that there was once a time when everything operated perfectly, no hangs or crashes, and then there was one discrete event which changed that.

Unf. there has never been a perfectly operating time, sorry to say.

Periodically restarting and moving on has been par-for-the-course. As long as it is not too frequent, it’s just typical friction to getting work done.

Yes, hanging is now much more frequent, so I agree that something changed. If I knew exactly what that was, I would just undo it, and not even post about it.

I’m trying to use tools to find out what is waiting for what, etc. To me, this is normal, logical, and even praiseworthy. I’m doing the best I can here.

The question I have for those who know far more about it than me is:

Is it possible to for a sufficiently knowledgeable person to determine the proximate cause of a hang using tools (and with the cooperation of the user, as needed)?

If it’s not possible, then I think I may be quite out-of-luck here.

Thanks for this information.

Re: memory -

I don’t think there is any issue with memory or swap, but I will be happy to follow instructions to generate any information that might indicate otherwise.

New code is a common, close-to-daily occurrence. How would I know if something was stuck in a loop? The 7-8% of CPU (shown up above) being reported as taken up during the hang does seem suggestive of that.

Plugins and rackspaces also change (in the aggregate) pretty often. If a plugin is hanging, is there no technical way (logging, dump analysis, whatever) to determine that fact and which plugin it is?

Windows did an update yesterday.

Hangs have been observed both before and after.

Switching Songs has initiated a hang more than once.

Aside: I know that Bitwig Studio, for example, has a fairly sophisticated way of “sandboxing” plugins. The net effect is that Bitwig pretty much never hangs or crashes.

Is GP at the direct mercy of the user’s plugins?

Got a hit …

C:\Users\Steve>netstat -an 1 | find “SYN”
TCP 192.168.1.13:50817 23.212.251.217:443 SYN_SENT

OK, then starting up GP added two more:

C:\Users\Steve>netstat -an 1 | find “SYN”
TCP 192.168.1.13:50817 23.212.251.217:443 SYN_SENT
TCP 127.0.0.1:50872 127.0.0.1:50513 SYN_SENT
TCP 192.168.1.13:50894 185.146.155.68:443 SYN_SENT

Then closed GP and restarted it. No entries this time.

Just edited a Song Part, deleting a MIDI event it had been sending, and changing the Song Part name. Upon clicking OK, GP hung.

This is not really possible in a live system because of the massive overhead and the free routing.
BitWig is a DAW with channel strip approach.

1 Like

Because it didn’t hang before and it did hang after?
By the way, what exactly is hanging? The GUI? Or does audio stop working? Or both?

I haven’t seen you perform any of the basic techniques to try and track this down, or at least, if you have, you haven’t reported them here.

For example:

  1. What happens if you disable scripting at startup?
  2. What happens if you disable the systems actions plugin at startup?
  3. What happens if you disable all your MIDI ports
  4. What happens if you start with a brand new empty gigfile and import the rackspaces one at a time?
  5. If you’re using OSC, what happens if you turn it off?

Have you used Bitwig as extensively as you have used GP? Have you written as much code for Bitwig as you have done for GP?

On what grounds do you assume that the problem is with a plugin?

What happens if you edit that song part and don’t delete the MIDI event, just change the name? What happens if you delete the MIDI event and don’t change the name
You may have a MIDI feedback loop or a GP Script loop somewhere. Have you used any script functions that are marked as experimental or dangerous? E.g, loading presets into plugins is not guaranteed safe - even though it seems to work with most plugins.

I have nothing else to add - the normal way to diagnose issues is to run tests to eliminate possible causes (medical doctors call that differential diagnosis) and you need to perform those tests. I can’t suggest anything else without more information.

2 Likes

The SYN state of a connection always occurs. Only when it us repeatedly reported (typically about 30 seconds) the connection doesn’t get established. netstat -an 1 reports all tcp sessions in any state and does that every second (that’s the meaning of the ‘1’). So you would have multiple lines of the same connection (until it times out, probably within 30 seconds)

Something like this:

The ip address you found is akamai. One of the largest cdn-providers in the world. It’s hardly possible that a NAS in your own network would have this ip-address, so I think that’s a false positive, unless one of the plugins is reaching out to akamai for an update.

Btw: if you extend the command like this (note the extra ‘o’), you get the program id making the connection. You could look that up in taskmanager:

netstat -ano 1 | find "SYN"

If that pid belongs to GP, one of the plugins probably causes this

1 Like

The short and important (IMO) overall answer to these 5 specific questions is that I would no longer be running the same system/setup that is hanging on me, nor would I be able to undertake the operations that I would normally be undertaking when the hangs happen.

If I turn off scripting, scripting won’t work, and I will have nothing here, just as if I’d turned off the computer itself. Etc. Etc.

That is why I ask:

Is it possible to for a sufficiently knowledgeable person to determine the proximate cause of a hang using tools (and with the cooperation of the user, as needed)?

This is not meant to a rhetorical question in the least;. Seriously!

Please answer it, simply and straightforwardly. Thanks.

Sometimes it is, sometimes it isn’t. This kind of issues tends to be solved only by meticulously ruling out possibilities and often this requires a lot of time.

A thing you could do is trying to divide the problem, for example always have a second instance of GP running, without plugins, scripts or extensions. Also all MIDI devices disabled, because these are not multi-client in most cases. Just the audio interface. This divides the issue in two possibilities: 1. it is a plugin issue. 2. Something else causes it.

If your normal GP instance suffers a hang and this empty GP also, then it’s less likely to be a plugin causing the issue, so something else causes it. Probably. Nothing is ever sure

BTW: Did you check event viewer to see if Windows had a problem going on at the times you experienced the problem? Check the application log and the system log. Keep in mind that not every warning or error has a real effect on your computer. But disk errors will (for example)

2 Likes

Good idea, thanks! I do see one entry that might be relevant, though I don’t know what to do with it.

On a sort of a hunch, I have turned off Record on all MRecorder plugins. I will report if a hang takes place anyway, or if I go a long time without one under these conditions.

That’s a crash of GP. If you can find the crash reports (as indicated in the event), it could point to an underlying issue.