MuWire goes into infinite loop, if the router is not available

MuWire conversation and discussion (found on: muwire.i2p)
Post Reply
User avatar
lgillis
Posts: 323
Joined: Mon May 09, 2022 8:40 am

MuWire goes into infinite loop, if the router is not available

Post by lgillis »

Screenshot (image/webp Size: 27.3 KB)

In my opinion, this is a double bug. Not only in that new notification windows are launched every second without limit, but these notification windows steal the focus. This prevents users from terminating the program in the conventional way.
My suggestion is to use the notification options provided by desktops. Alternatively, there may be unused space in the main window.
zlatinb
Posts: 14
Joined: Thu Jul 18, 2024 6:42 pm

Re: MuWire goes into infinite loop, if the router is not available

Post by zlatinb »

I was just looking into this bug and it is going to be a difficult fix. I can stop the windows from appearing but once MuWire loses connection to the router it goes into a broken state - it will not connect or be fully functional again and the best thing to do is to kill it and restart it.

I expect I will need at least a few months to fix it as I don't have a proper dev environment set up yet. Sorry about that.
User avatar
lgillis
Posts: 323
Joined: Mon May 09, 2022 8:40 am

Re: MuWire goes into infinite loop, if the router is not available

Post by lgillis »

No problem, I can adjust to that. Then I simply switch off MuWire before the operating system update-program restarts I2Pd.

One more little thing for which I don't want to start an extra thread. Under Linux, 2 warnings are issued during startup. This is not a problem, but could raise questions for new users. If “uname” is saved in a variable in the script further above, then “DEFAULT_JVM_OPTS” can be configured appropriately for the respective operating system via “case”. Here only for clarification, I know that there is a more elegant way:

#+begin_src sh
OS=$(uname)
case "${OS}" in
Linux) DEFAULT_JVM_OPTS=… ;;
Darwin) DEFAULT_JVM_OPTS=… "--add-exports" "java.desktop/com.apple.laf=ALL-UNNAMED" ;;
*) DEFAULT_JVM_OPTS=… "--add-opens" "java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED" ;;
esac
#+end_src

And Flymake claims, in POSIX sh, ulimit -H and -n is undefined.

;-)
zlatinb
Posts: 14
Joined: Thu Jul 18, 2024 6:42 pm

Re: MuWire goes into infinite loop, if the router is not available

Post by zlatinb »

I've noticed those warnings, and it's quite tricky to get rid of them because the bin/MuWire script gets generated during build time from some Gradle template I haven't looked into yet. (If you look through the source tree you will see that there is no such script anywhere)

I'll put it on my todo list. It's silly that the jvm uses stdout/stderr for these kinds of warnings...
User avatar
lgillis
Posts: 323
Joined: Mon May 09, 2022 8:40 am

Re: MuWire goes into infinite loop, if the router is not available

Post by lgillis »

I looked at the script called "gradlew" and was amazed at the high number of typical beginner errors. I don't know anything about Java myself, so I think it's good to get some pointers that help me when it comes to the quality of source code. Because when I go online with an application around the clock, I expect a high level of built-in security. And that includes adhering to the primary virtues of programming. So in my case, the JVM warning led me to run a static code analysis over the entire source code. From this point of view, the warning was by no means silly, but an advantage for users like me.
zlatinb
Posts: 14
Joined: Thu Jul 18, 2024 6:42 pm

Re: MuWire goes into infinite loop, if the router is not available

Post by zlatinb »

The gradlew (which stands for "Gradle wrapper") is only used to download the specific version of the Gradle build tool. Once MuWire is built, Gradle does not enter into play anymore.

Some Linux distributions offer Gradle in their package repositories. That may or may not work with MuWire, depending on the version of Gradle is being shipped. In the source tree, look at the file gradle/wrapper/gradle-wrapper.properties which contains the version - currently 7.3.1. If your distribution offers that or newer version, you should be able to use that - instead of ./gradlew assemble type gradle assemble (it will be picked from $PATH).

Regarding static code analysis, majority of MuWire is written in Groovy, with only some of the performance-critical parts in Java.
User avatar
lgillis
Posts: 323
Joined: Mon May 09, 2022 8:40 am

Re: MuWire goes into infinite loop, if the router is not available

Post by lgillis »

I think we're talking at cross purposes. I hope that's not intentional.
> I looked at the script called "gradlew"
#+begin_src
Commit 26f4e41d57cad6c76e128744d55480ae2b45c2bc
Author: Zlatin Balevsky <privacy>
AuthorDate: Fri May 31 17:06:39 2019 +0100
Commit: Zlatin Balevsky <privacy>
CommitDate: Fri May 31 17:06:39 2019 +0100

Parent: 096f784d share files from UI
Contained: master
Precedes: muwire-0.0.1 (1)

add gradle wrapper

1 file changed, 172 insertions(+)
gradlew | 172 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

new file gradlew
@@ -0,0 +1,172 @@
+#!/usr/bin/env sh
+
+##############################################################################
+##
+## Gradle start up script for UN*X
+##
+##############################################################################

[snip]
#+end_src

And as far as the source code is concerned, you should perhaps consult someone who does this professionally.
;-)
zlatinb
Posts: 14
Joined: Thu Jul 18, 2024 6:42 pm

Re: MuWire goes into infinite loop, if the router is not available

Post by zlatinb »

lgillis wrote: Mon Jul 29, 2024 7:35 am Screenshot (image/webp Size: 27.3 KB)

In my opinion, this is a double bug. Not only in that new notification windows are launched every second without limit, but these notification windows steal the focus. This prevents users from terminating the program in the conventional way.
My suggestion is to use the notification options provided by desktops. Alternatively, there may be unused space in the main window.
In my latest commit I fixed the infinite loop issue. MuWire now reconnects successfully when the I2P router comes back up.

There is something strange though - it will reconnect to the other MuWire nodes it knows about much slower after such an event. I'm not sure what's causing this and will probably look into it at some point in the future.

You can either build from source or get the latest build from the GitHub continuous integration page if you want to test.
Post Reply