Using right-click 'Jump to declaration' menu item causes Processing to lock-up in some sketches.

[processing-bot]

Created by: matkeane

Description

Using right-click 'Jump to declaration' menu item causes Processing to lock-up in some sketches.

When selecting a variable or function name in the UI and clicking on 'Jump to declaration' Processing locks up - No error is shown in the console but the UI becomes unresponsive, menus no longer open and windows cannot be opened or closed. I did wonder if things were just slow, but 10-15 minutes later, Activity Monitor shows Processing as 'not responding' but using between 25-25% CPU.

I first noticed the problem when working on my own projects, so it's quite possible there's something horrible about my code which is triggering this (my current project has a few thousand lines of code in 28 files, so quite likely I guess). Having said that, the same project didn't trigger this problem using Processing 3.5.4, I only encountered this after opening the project in Processing 4. Different versions of the project compile and run without errors under versions 3 & 4 of Processing.

While the problem doesn't occur when opening single-tab examples or sketches, it does happen with some of the multi-file example code from the 'Generative Design' book, but doesn't occur when testing a sketch by Marius Watz in 2 tabs.

In addition to controlP5 (which doesn't trigger the error in other sketches) my current project imports the following libraries:

import java.util.Locale;
import java.awt.datatransfer.*;
import java.awt.Toolkit;
import java.io.FileInputStream; // File Streams.
import java.io.FileOutputStream;
import java.util.UUID;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

Expected Behavior

In Processing 3, the 'Jump to declaration' menu item would jump straight to the appropriate variable/function declaration.

Current Behavior

In version 4, 'Jump to declaration' sometimes causes Processing to become unresponsive.

Steps to Reproduce

Some of the sketches which trigger the problem import external libraries, but I haven't found a sketch (other than my own) which always triggers the problem.

Your Environment

• Processing version: Processing 4.0b8
• Operating System and OS version: Mac OS 10.15.7

[processing-bot]

Created by: benfry

Hm, sorry to hear it. That code hasn't changed between 3 and 4, but it sounds like you're hitting a threading deadlock (the spinning) so it may have been broken in 3 but less likely to be hit. (Also means that on someone else's machine, they may hit the problem).

If you can track it down to a reproducible example, that'd be really helpful so we can see what might be happening.

[processing-bot]

Created by: matkeane

OK, so after some more experimenting, it seems like none of the Processing example sketches cause this problem, and some of my sketches always cause the problem - so maybe my messy code is the real problem! However, after taking an old sketch of mine which did cause the problem and moving all the code to a single tab (making it even messier in the process), 'jump to declaration' seems to work fine (or at least hasn't caused Processing to hang since). So could the issue be related to projects with multiple tabs (originally this test project had 10)?

[processing-bot]

Created by: matkeane

Example sketch attached with the original multi-tab files which cause the crash for me, and a single-file version which doesn't cause the crash when selecting 'jump to declaration':

processing_example_01.zip

[processing-bot]

Created by: benfry

Thanks for the example; will try to take a look, or perhaps someone will volunteer to check into it.

[processing-bot]

Created by: matkeane

Thanks! That code was taken from an older project, repurposed for something new and then never finished, so maybe Processing is crashing in protest at the sheer messiness. But, interestingly, I just tried opening the project - which systematically causes the crash on my Mac - on a Windows 10 machine (4b08) and no amount of right-clicking managed to cause the problem. Is there something specific to multi-threading on Macs perhaps?

[processing-bot]

Created by: benfry

Related: #551

[processing-bot]

Created by: ssanter

I'm encountering the same issue on mac book pro 12.6, using processing ide 4.0.1. while using single file (ie not multi-tabbed project)

[processing-bot]

Created by: benfry

If you have a nice, short example sketch, and a sequence of steps that reproduces the problem, that'd be super helpful.

[processing-bot]

Created by: clankill3r

@matkeane

Does this example freeze up for you if you jump to the declaration of chars?

void test_hslab() {
  char[] chars = {'H', 'S', 'L', 'A', 'B'};
}

void test_hslab_2() {
  char[] chars = {'•', 'H', 'S', 'L', 'A', 'B'};
}

[processing-bot]

Created by: matkeane

Does this example freeze up for you if you jump to the declaration of chars?

Hi. Yes, I dropped that code into a new test sketch and Processing locked up when I tried 'jump to declaration'.

[processing-bot]

Created by: benfry

Still can't get this to happen on any of my machines… Clearly a thread deadlock problem but I can't find a good case to trigger it. I'm a little less familiar with that code because it came from a GSoC project, so if anyone wants to take a look, please do so.

[processing-bot]

Created by: ssanter

sorry for the late reply— but yes, that code freezes for me too when jumping to declaration of chars

[processing-bot]

Created by: matkeane

Just an update: I can reproduce the issue - in both my code and the example provided by @clankill3r - in the recently released v4.2 on a new M1 MacBook Pro.

With the test code above (#527 (comment)), if I remove the first character '•' in the second array definition, the error no longer occurs.

[processing-bot]

Created by: benfry

Still can't reproduce here:

[processing-bot]

Created by: matkeane

So I just did a search-and-replace for all non-ascii characters (using this regexp [^\x00-\x7F] ) in my own code, and with those characters stripped out, right-clicking / cmd+clicking and selecting a menu item, no longer causes things to lock up.

As in the test code above, the non-ascii characters are always quoted in strings, not in variable to class names. Strange that it only happens on some machines though - is it possible it's related to OS language settings ?

I was a bit confused at first, as the unicode arrows which seemed to be causing the problem were a recent addition to UI text, and the problem predated their addition. But I tracked down a copyright symbol - © - which has been there forever and removing that seems to reliably avoid the problem.