# Vuze cashes at start

## dufeu

I performed a world update recently and 'vuze' now crashes on startup. When I execute 'vuze' from a terminal window, I get

```
Creating /home/guynonet/.azureus

Creating /home/guynonet/.azureus/gentoo.config

$UI not set defaulting to swt

file:/usr/share/vuze/lib/Azureus2.jar ; file:/usr/share/commons-cli-1/lib/commons-cli.jar ; file:/usr/share/commons-lang-2.1/lib/commons-lang.jar ; file:/usr/share/json-simple/lib/json-simple.jar ; file:/usr/share/log4j/lib/log4j.jar ; file:/usr/share/swt-3.8/lib/swt.jar ; file:/home/guynonet/

changeLocale: *Default Language* != English (United States). Searching without country..

changeLocale: Searching for language English in *any* country..

changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)'

DEBUG::Wed Jan 11 10:30:57 EST 2017  Successfully migrated key management

UIFunctions/ImageLoad took 25ms

new shell took 126ms

new shell setup took 50ms

skin init took 126ms

MainMenu init took 100ms

pre skin widgets init took 25ms

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00007f6dbedef150, pid=9151, tid=140106790766336

#

# JRE version: OpenJDK Runtime Environment (7.0_121) (build 1.7.0_121-b00)

# Java VM: OpenJDK 64-Bit Server VM (24.121-b00 mixed mode linux-amd64 compressed oops)

# Derivative: IcedTea 2.6.8

# Distribution: Gentoo Base System release 2.2, package Gentoo icedtea-7.2.6.8

# Problematic frame:

# C  [libc.so.6+0x8d150]

#

# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

#

# An error report file with more information is saved as:

# /home/guynonet/hs_err_pid9151.log

skin widgets (1/2) init took 302ms

#

# If you would like to submit a bug report, please include

# instructions on how to reproduce the bug and visit:

#   http://icedtea.classpath.org/bugzilla

#

Aborted
```

I've tried a number of different things:Moving ~/.azureus to a backup directory thus forcing 'vuze' to create a new one. Here, I'm looking for possible session corruption.

Running 'vuze' from an account vuze has never been run on {new test account to guarantee no prior session corruption}. 

Checking recently updated packages against immediate dependencies for 'vuze'

From /var/log/emerge.log:

```
1484102767:  *** terminating.

1484104818: Started emerge on: Jan 10, 2017 22:20:18

1484104818:  *** emerge --update --keep-going --newuse --quiet-build=y --with-bdeps=y --deep @world

1484105082:  >>> emerge (1 of 44) dev-lang/mujs-0_p20161202 to /
```

```
app-benchmarks/bonnie++

app-crypt/gnupg

dev-lang/mujs

dev-lang/php:7.0

dev-libs/libevdev

dev-libs/libpwquality

dev-libs/nss

dev-perl/Exception-Class

dev-perl/IO-Socket-INET6

dev-perl/IO-Socket-SSL

dev-perl/Net-HTTP

dev-perl/Net-SSLeay

dev-perl/Socket6

dev-perl/glib-perl

dev-ruby/rdoc

dev-util/colm

dev-util/gperf

dev-util/ragel

dev-vcs/mercurial

gnome-base/gvfs

kde-apps/ark

kde-apps/kdesdk-kioslaves

kde-apps/krdc

kde-apps/pykde4

kde-plasma/plasma-desktop

kde-plasma/plasma-integration

media-libs/harfbuzz

media-libs/jasper

media-libs/libpng:0

media-libs/mesa

net-libs/gnutls

net-libs/liblockfile

net-misc/openvpn

net-misc/youtube-dl

net-p2p/transmission

sys-apps/ed

sys-apps/kbd

sys-apps/openrc

sys-apps/sed

sys-kernel/gentoo-sources:4.8.17

sys-kernel/gentoo-sources:4.9.2

virtual/perl-IO-Socket-IP

x11-libs/gtk+:3

x11-libs/gtksourceview:3.0

x11-libs/libva

x11-terms/xfce4-terminal
```

The only package in this list which seems applicable by inspection is "dev-lang/mujs". However, only installed package dependent on mujs appears to be:

```
 * These packages depend on dev-lang/mujs:

app-text/mupdf-1.9a (>=dev-lang/mujs-0_p20160504)
```

 which is unrelated.

None the less, I downgraded mujs and tried opening vuze again with no better result.

I also downgraded x11-libs/gtk+:3 {3.22.5==>3.22.4} 

Research via google hasn't lead to positive results nor has looking in bugsilla.gentoo.org.

At this point, I don't know what else to try. Suggestions?

BTW - In the meantime, I'm now trying out qbittorrent. If that should fail my 'just works' expectations, I'll only be left with rtorrent to try. I'm basically restricted to 'whitelisted' torrent clients on certain private trackers.

----------

## audiodef

I know this isn't an answer, but I gave up on vuze/azureus long ago because of bs like this. My current client is qtransmission, and there are other, more-reliable-than-vuze torrent clients out there. 

I even had trouble with it on Windows.   :Rolling Eyes: 

----------

## virtguru

What java vm settings do you have for the user ? Are you using any specific class paths ? 

```

Creating /home/guynonet/.azureus/gentoo.config

$UI not set defaulting to swt 

```

You mentioned that you did a world update was your java updated as well ? From the snippet you posted there also appears to be something going on with the jvm, unfortunately Im not using icedtea due some other work related reasons. Regardless , this may not be very security minded but just for testing sake does it start up with root ? What about trying a different java vm ?

----------

## cameta

```
(Vuze:3771): GLib-GObject-CRITICAL **: g_closure_add_invalidate_notifier: assertion 'closure->n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed

(Vuze:3771): GLib-GObject-CRITICAL **: g_closure_add_invalidate_notifier: assertion 'closure->n_inotifiers < CLOSURE_MAX_N_INOTIFIERS' failed

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00007f95519a75f0, pid=3771, tid=140276324480768

#

# JRE version: OpenJDK Runtime Environment (7.0_121) (build 1.7.0_121-b00)

# Java VM: OpenJDK 64-Bit Server VM (24.121-b00 mixed mode linux-amd64 compressed oops)

# Derivative: IcedTea 2.6.8

# Distribution: Gentoo Base System release 2.2, package Gentoo icedtea-7.2.6.8

# Problematic frame:

# C  [libc.so.6+0x8e5f0]

#

# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

#

# An error report file with more information is saved as:

# /home/mestres/hs_err_pid3771.log

#

# If you would like to submit a bug report, please include

# instructions on how to reproduce the bug and visit:

#   http://icedtea.classpath.org/bugzilla

#

Aborted

```

I have the same problem.

----------

## cameta

```
tux mestres # eselect java-vm list

Available Java Virtual Machines:

  [1]   icedtea-bin-7 

  [2]   icedtea-bin-8  system-vm
```

I have tried both VM and the same error

I have updated to vuze-5.7.2.0 and nothing.  :Sad: 

----------

## cameta

Transmission very good.   :Very Happy: 

----------

## virtguru

wonder if something in icedtea , working for me on oracle-jdk system-vm

----------

## Melf

It seems to be a bug related to icedtea. I had that idea from this bug 

https://bugs.gentoo.org/show_bug.cgi?id=581186 and the message from virtguru  *Quote:*   

> wonder if something in icedtea , working for me on oracle-jdk system-vm

 

Re-emerging icedtea with

```

CFLAGS="" CXXFLAGS="" emerge -1 =dev-java/icedtea-3.2.0

```

fixed it for me. I did not test it with icedtea-7, but probably the same applies. Somehow I have the feeling that there is a third package causing the error, because in the last update I did not change something with icedtea...

----------

## cameta

Tested for  icedtea-7, 

 *Quote:*   

> CFLAGS="" CXXFLAGS="" emerge -1 =dev-java/icedtea-bin-7.2.6.8 

 

Didn't fix it for me.

----------

## Melf

The dev-java/icedtea-bin package is probably already compiled with the -02 optimization. As it is a binary, it makes no sense to use the CFLAGS-variables. If you want to test icedtea-7, you need to run

```

CFLAGS="" CXXFLAGS="" emerge -1 =dev-java/icedtea-7.2.6.8

```

I started it now, but it takes about 30 min to compile on my system.

----------

## Melf

It is now starting with icedtea-7 too. My java-config looks like this:

```

The following VMs are available for generation-2:

*)   IcedTea JDK 7.2.6.8 [icedtea-7]

2)   IcedTea JDK 3.2.0 [icedtea-8]

```

I have to admit that I do not really know if my problem is related to yours. Maybe it was just a lucky guess based on bug 581186. When I still had the bug, it looked to me like some kind of race condition, because one time vuze was starting and the other times it just crashed, but each time there were different exceptions shown in the command line. I have no idea how to make a helpful bug report of this behavior right now.

----------

