Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
List-selection causing UI lockups (Linux, headless Xvnc — NOT the GTK3 issue)
I've been having a minor problem for quite a while now (months, maybe years) with the Vuze Classic UI freezing up (but the program still running) in certain situations, which seem to be related to list-selection / scrolling.

The trigger seems to be an action that causes one of the torrent lists to scroll while interacting with it. The simplest and most reliable way to reproduce the problem:
  1. Make sure the torrent list is longer than the visible area (needs to scroll)
  2. Select a row
  3. Shift-PageDown (or Shift-PageUp) to multi-select a set of torrents which extends out of the viewport (would cause the list to scroll)
In my experience, at least 80% of the time this will cause the entire UI to lock up, unrecoverably.

Other operations, such as dragging to reorder list items, can also trigger a freeze, but the common thread appears to be the list attempting to scroll while another interaction is in progress. Scrolling without selecting/dragging is never a problem, it takes the two in combination.

In all other ways the application is still running — transfers continue and complete, RSSFeed Scanner continues to update, I can remotely add torrents or access the HTML Web UI and interact with it. It's just that the main GUI is frozen, or (if I minimize-and-restore the window) blank. I've left a frozen Vuze running for multiple minutes to see if it would recover (allowing all of the in-progress transfers complete, which they did), but it never comes back to life. The only way to recover is to kill Vuze / close the main window (which causes the window manager to show a "This window is not responding" dialog), then relaunch it.

I'm running the latest release ( installed in my home directory, using SWT v4508, under Java 1.7.0_71 on Fedora 20 x86_64 (Linux v3.17.3-200.fc20.x86_64). Vuze is running on an Xvnc display, accessed over an SSH-tunnelled connection to port 5901. I've tried to rule out environmental factors as much as possible (including stripping all JAVA_ARGS from my startup script other than "-Dazureus.log.stdout=0") but nothing's made any difference.

This is not the GTK3 bug — I did add "export SWT_GTK3=0" to my startup script, but the problem still occurs.

It's kind of an esoteric issue, doesn't really impact functionality much, and the workaround of "just don't do that" has been pretty serviceable, so I've put off bringing it up until now. But the recent discussion of other Linux UI troubles reminded me of the issue, and I wanted to get it out there.
And, if I wasn't inept at searching, I'd have realized before posting that this was a duplicate of Hieronymus's report from three weeks ago.
Hmm, tried your steps on my Linux VM and couldn't reproduce it.

Perhaps you could try reproducing it and then grabbing a thread dump by browsing to this exact URL;0;config;log-diags;;

(including the trailing ;;) in your browser.

Then kill Vuze and grab the debug_1.log and debug_2.log and look for some stack traces - send em over if they're there.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Shutting down Vuze in order to not get "Vuze did not shutdown cleanly" megatron 0 2,143 03-06-2020, 11:28 AM
Last Post: megatron
Question Tray icon, not functional (Linux). Achilleus 0 2,765 01-07-2019, 08:33 PM
Last Post: Achilleus

Users browsing this thread: 1 Guest(s)