Application crashes when starting (since last update)

[ndsvw]

Describe the bug When I start the application, it crashes immediately (it just does not open).

To Reproduce Steps to reproduce the behavior:

1. Start the application
2. See error

Expected behavior No crash. Normal UI opens instead of "Ein Fehler ist aufgetreten"

Screenshots

Desktop (please complete the following information):

• OS: Linux
• Version 0.6.4 (latest)

The logs: 1687452935688.log

[Morpheus1w3]

You should have a folder called .eclipse at your user folder. After deleting them the app should work as intended.

[ndsvw]

Yes, thanks. That worked. Can start it again. 👍 It's solved for me.

[buchen]

Somehow this is related to flat hub. I do not really know why the setup there fails. For now, I will add a notice to the update

[buchen]

Allerdings werden die Update Meldungen beim einem Update via Flathub gar nicht angezeigt... der Update läuft ja via Flathub. Das muss ich mir mal einarbeiten.

[Morpheus1w3]

@buchen Isn't it possible that the Flatpack app store localy the version number and checking at runtime the URL https://api.github.com/repos/buchen/portfolio/releases/latest? Something like these example?

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
import org.json.JSONObject;

public class Main {
    private static final String API_URL = "https://api.github.com/repos/{owner}/{repo}/releases/latest";

    public static void main(String[] args) throws Exception {
        // Replace {owner} and {repo} with actual owner and repository name
        URL url = new URL(API_URL.replace("{owner}", "actual_owner").replace("{repo}", "actual_repo_name"));

        HttpURLConnection conn = (HttpURLConnection) url.openConnection();
        conn.setRequestMethod("GET");
        conn.setRequestProperty("Accept", "application/vnd.github.v3+json");

        if (conn.getResponseCode() != 200) {
            throw new RuntimeException("Failed : HTTP error code : " + conn.getResponseCode());
        }

        BufferedReader br = new BufferedReader(new InputStreamReader((conn.getInputStream())));
        StringBuilder output = new StringBuilder();
        String line;
        while ((line = br.readLine()) != null) {
            output.append(line);
        }
        conn.disconnect();

        JSONObject json = new JSONObject(output.toString());
        String latestVersion = json.getString("tag_name");

        // Compare latestVersion with stored version and if newer, send notification
    }
}

[buchen]

Isn't it possible that the Flatpack app store localy the version number and checking at runtime the URL

My understanding is:

flathub is regularly checking github and updating the binaries - and the the update is pushed via flat hub mechanism. That is pretty fast - after I publish a new release, there is almost immediately a new pull request on the flathub project. The embedded update mechanism of PP is deactivated in the flathub install because otherwise they would conflict with each other (and PP has no permissions to self-change the binaries there).

https://github.com/flathub/info.portfolio_performance.PortfolioPerformance/blob/master/info.portfolio_performance.PortfolioPerformance.json#L47-L59

What I do not yet understand is how and where to put the release notes. Those are currently embedded into the P2 update mechanism (which is not used by flat hub). The release notes would be a place to inform the user that possibly deleting the .eclipse can help.

But the root cause here is that the flat hub installation for one reason or another leads to the creation of the .eclipse directory. In my understanding, a regular install is not creating/using this file.

[Morpheus1w3]

Based on ChatGPT

Flatpak applications are run in a sandboxed environment, which can lead to issues accessing certain directories on your system. If you are having a problem with Flatpak's Eclipse accessing the .eclipse directory, it might be due to the sandboxing.

If you need to allow access to certain directories, you can override the sandbox permissions on a per-application basis.

For instance, if you need to give your Flatpak Eclipse instance access to the .eclipse directory, you could use a command like the following:

flatpak override --user --filesystem=~/.eclipse org.eclipse.Java

In this command:

• flatpak override is the command to change the permissions of a Flatpak application.
• --user indicates that this override should apply to the current user.
• --filesystem=~/.eclipse grants access to the .eclipse directory in the user's home directory.
• org.eclipse.Java is the application ID of the Flatpak Eclipse instance. This might be different on your system.

After running this command, Eclipse should have access to the .eclipse directory.

In Flatpak, overrides are not typically written into the Flatpak definition file (.flatpakref or .flatpakrepo or the manifest .json). Instead, they are usually set after the application has been installed, using the flatpak override command.

However, if you are packaging the application yourself and you know that it will require access to certain parts of the filesystem, you can add the --filesystem option to the finish-args section of the application's Flatpak manifest (.json or .yaml file).

Here is an example of what the finish-args section might look like with this option:

"finish-args": [
    "--share=ipc",
    "--socket=fallback-x11",
    "--socket=wayland",
    "--device=dri",
    "--filesystem=~/.eclipse"
],

In this example, the --filesystem=~/.eclipse line gives the application access to the .eclipse directory in the user's home directory.

Please note that giving applications access to parts of the filesystem can potentially be insecure. You should only do this if necessary and if you understand the potential risks.

Also note that these changes will apply to anyone who installs the application from your Flatpak package. If you are not the packager of the application, but you want to change the permissions for your own use, it would be more appropriate to use the flatpak override command after installing the application.

[Morpheus1w3]

https://github.com/flathub/info.portfolio_performance.PortfolioPerformance/pull/68

If someone wants to test this change

flatpak install --user https://dl.flathub.org/build-repo/32167/info.portfolio_performance.PortfolioPerformance.flatpakref

[roshanshariff]

This isn't the right change to be making, and in fact we already give the Portfolio Performance flatpak access to the user's home directory. This is why it is able to create/access the ~/.eclipse directory in the first place. I'm also unsure why this directory is being created only when running in Flatpak and not otherwise.

@buchen, there is indeed an automated process that updates the Flatpak manifest every time you release a new version, but unfortunately doesn't get the associated release notes. Flatpak (like many other Linux package managers) uses AppStream metadata XML files for release and changelog information. We provide a basic one, but if you include this file in your source repository you could also include release notes. For each new release, you'd have to add a release tag containing a description child.

Let me know if you'd be willing to include this file in your Linux releases, and we can set up the Flatpak build to just use it directly. And, of course, since it's not Flatpak-specific, it would also benefit other distribution packagers.

[roshanshariff]

I'm attaching a directory listing of a freshly created ~/.eclipse directory to help in understanding what it's for and why it's being created. Perhaps it normally goes in a temporary location? If so, we can figure out how to make that happen in Flatpak as well.

[buchen]

@roshanshariff @Morpheus1w3

This is my understanding after doing some research:

• Eclipse applications require a configuration directory to run. The documentation says: "Configuration locations contain files which identify and manage the (sub)set of an install to run."
• By default, Eclipse applications write this into the installation directory (btw, this is where I find it on macOS...)
• If that directory is read-only (and no alternative l location is given), then the code tries to come up with a unique installation identifier and uses a sub-directory of ".eclipse". In the sample directory listing above, I assume it came up with "1412530840_linux_gtk_x86_64".
• It is possible to configure the location by setting the parameter osgi.configuration.area

What I do not understand: Why was it failing in this particular update (when upgrading Eclipse libraries itself): If Eclipse picks the same configuration directory identifier, why couldn't it update the configuration area properly? And if it picked a new configuration area, well, isn't it just like a fresh install?

What we can do for flathub: we could add a defined location for the configuration area. My understanding is that it requires adding the parameter to the config.ini - similar to the others. I have created a pull request, but not tested it locally.

[roshanshariff]

@buchen, I was also looking into this and came to a similar conclusion. From the documentation on multi-user installs, it appears that Eclipse uses the configuration directory inside the Portfolio Performance installation if it is writable. In Flatpak, the installation is read-only, so it falls back to ~/.eclipse/<product-id-version>/configuration.

After some testing, I couldn't reproduce the crash on startup when I installed PP 0.63.1, let it create a configuration area, and upgraded it to version 0.64.1 with the same configuration area. However, the directory does contain some .so files and I can imagine that some versions of Eclipse may not properly handle them being out-of-date.

The remaining question is where this directory should be located. I am testing a patch similar to your pull request, but if we use a common configuration area across different versions of PP, then presumably we will keep having these crashes. On the other hand, if we use a different configuration area for each PP or Eclipse version, then old versions will accumulate. I'm not sure what a reasonable solution to this problem is, since I'm not sure what is causing these crashes in the first place.

[buchen]

My 2 cents:

we use a common configuration area across different versions of PP

I would propose to use a common area. How often will users have multiple different installations of PP?

since I'm not sure what is causing these crashes in the first place

I checked. In the past, the update of the Eclipse framework did not cause similar problems with Flatpak. It was only this version update. My gut feeling is that this was the exception, not the norm.

Next framework update will be in 3 or 6 months. I'll try to remember to do a test beforehand with flathub.

[buchen]

About AppStream file: I'll have a look. Right now, I am creating the release notes as bullet points inside a Java property file - and then copy it to the web site, the github description of releases, and (in modified form) to the forum. It sounds like it could be easier to maintain them in XML and generate the other output. I'll have a look (have to check how to work with languages - German and English)

[roshanshariff]

I've included the change along with the update to Portfolio Performance 0.64.2, now published on Flathub. The crash issue should now be resolved. We can investigate it further if it arises again, but deleting/moving ~/.var/app/info.portfolio_performance.PortfolioPerformance/config/configuration would fix it at least.

@buchen In the AppStream file, the release notes inside the <description> tag can be translated element-by-element. For example

...
    <release version="0.64.2" date="2023-07-14">
      <description>
        <ul xml:lang="de">
          <li>Neu: Filter-Konfigurationen werden jetzt nicht mehr in den Einstellungen sondern in der Datei selber gespeichert. Damit können die einfacher zwischen Rechnern synchronisiert werden und besser editiert werden</li>
          <li>Neu: MACD Indikator im Kursdiagramm (Moving Average Convergence/Divergence) (zu Deutsch: Indikator für das Zusammen-/Auseinanderlaufen des gleitenden Durchschnitts)</li>
          <li>Neu: das Measurement Tool ist jetzt für alle aktive - damit kann man einfach in den Diagrammen Abstände und Änderungen messen</li>
          <li>Verbesserung der PDF Importer: LGT Bank, sBroker, Bondora, FlatEx, Trade Republic, Vanguard</li>
          <li>Verbesserung: Weitere Möglichkeiten neue Wertpapiere anzulegen: per Tastaturkürzel Ctrl-N, über das (+) Symbol neben "Wertpapiere" in der Seitennavigation</li>
          <li>Verbesserung: Tabellen aus den Tooltips merken sich die Spaltenbreiten</li>
          <li>Verbesserung: Tooltip zu den Erträgen pro Jahr enthält jetzt alle Jahre</li>
          <li>Verbesserung: Spalten mit dem Ticker Symbol bei den Klassifizierungen</li>
          <li>Fix: Aktualisierung des aktuellen Kurses über Yahoo Finance wieder möglich</li>
        </ul>
        <ul xml:lang="en">
          <li>New: Filter configurations are no longer stored in the settings but in the file itself. This makes it easier to synchronize them between computers and to edit them better</li>
          <li>New: MACD indicator in the price chart (Moving Average Convergence/Divergence)</li>
          <li>New: the Measurement Tool is now active for all - it allows to easily measure distances and changes in the charts</li>
          <li>Improvement of PDF importers: LGT Bank, sBroker, Bondora, FlatEx, Trade Republic, Vanguard</li>
          <li>Improvement: More possibilities to create new instruments (securities, crypto currencies, etc): via keyboard shortcut Ctrl-N, via the (+) symbol next to "Securities" in the page navigation</li>
          <li>Improvement: Tables from the tooltips remember the column widths</li>
          <li>Improvement: tooltip for yields per year now contains all years</li>
          <li>Improvement: columns with the ticker symbol in the classifications</li>
          <li>Fix: Update of latest price via Yahoo Finance is fixed</li>
        </ul>
      </description>
    </release>
...

I've verified that this format passes the AppStream validator.

[roshanshariff]

@buchen, this problem seems have come back with the Eclipse framework upgrade in 0.65.4. For the Flatpak version, you have to manually rm -r ~/.var/app/info.portfolio_performance.PortfolioPerformance/config/configuration to avoid a crash after upgrading from a previous version.

Do you have any thoughts on how to make the configuration area robust to upgrades?

EDIT: For now I decided to work around this problem in the Flatpak by putting the configuration area in $XDG_RUNTIME_DIR, which defaults to /run/user/$UID/.... This is a tmpfs that is cleared whenever the user session ends. This is not ideal because the tmpfs is backed by RAM and the configuration area uses up around 5 MB after you've run PP.

EDIT2: I found that adding the osgi.clean option to config.ini also works around the problem, forcing the Eclipse platform to regenerate its caches on startup. See flathub/info.portfolio_performance.PortfolioPerformance#92.