Java process hung upon game quit, launcher does not re-apppear and becomes inoperable about prismlauncher HOT 13 CLOSED

Feel free to request more information with directions on any specific logs or commands you'd like me to run when the issue is present/has been present in my desktop session.

from prismlauncher.

Is this happening with a specific instance or all of them? Does a vanilla instance(no modloader) behave the same?

from prismlauncher.

Is this happening with a specific instance or all of them? Does a vanilla instance(no modloader) behave the same?

Good question, I'm unsure whether the issue occurs with other instances. Currently running FTB Genesis (1.19.2) with OpenJDK JVM 17.0.9

I can check and see if it does the same tomorrow with a Vanilla instance.

from prismlauncher.

I was unable to reproduce the issue in another modpack with the same game version nor in a vanilla instance. However, that does not necessarily mean it is not present. I suspect that there may be some time/actual use required to reproduce the issue which I was not able to perform as part of a quick test.

from prismlauncher.

Ok that means it is a problem with a mod from that modpack that causes the game to not quit(this is not a launcher bug).
Try disabling them until it doesn't happen anymore. My guess try disabling ftb chunks.

PS. The Prism discord server is a better place to find help regarding this kind of issue

from prismlauncher.

Ok that means it is a problem with a mod from that modpack that causes the game to not quit(this is not a launcher bug).

I do not agree with this assessment. I attempted to specify in my last comment that I suspected a level of extended interaction (longer playtime) with any particular instance than I am currently able to devote.

Try disabling them until it doesn't happen anymore. My guess try disabling ftb chunks.

A) It is not a good idea for a casual user to begin arbitrarily disabling and removing modifications from a prescribed modpack in an unlikely effort to catch an issue that seems much more likely to be a Java implementation issue or launcher issue. I do not believe that a mod working within the confines of a mod loading library is capable/likely of introducing such a significant issue as preventing the proper clean-up of the game process and the launcher status. Keep in mind that the issue is not only leaving the game process running in the background, but is also leaving the launcher process open and hidden as well.

B) I do not expect the issue to be with FTB Chunks as the other modpack that I tested also includes the same version of FTB Chunks and did not reproduce the issue.

I will also mention that the response received comes off as condescending and unhelpful, that as well as unilaterally closing the issue as wontfix without any noted attempt to reproduce is rather rude. I also believe that Discord is not the correct forum to be referring to for support regarding a suspected issue of this caliber, especially not from a forum that is dedicated to bug reporting.

from prismlauncher.

To clarify, I'm not here for user support. I'm here to report a suspected issue with the launcher that I am experiencing, of which the team responsible for development should be made aware. I am capable of terminating the rogue process myself when the issue occurs. GitHub issues exist to make the developer aware of potential issues with a product that they maintain. Discord is not only too ephemeral for it to be a a reliable store of information, but also more relevant for someone seeking user support for an ongoing minor issue as previously mentioned.

My impetus for coming directly to this project to report and not to another location is that the launcher is used to spawn the Java process which runs the game, it is the parent process of the Java VM in this case and as such should be responsible for the cleanup of said process if it is not successfully self-terminating.

from prismlauncher.

I do not agree with this assessment. I attempted to specify in my last comment that I suspected a level of extended interaction (longer playtime) with any particular instance than I am currently able to devote.

If you do not have time to devote to your issue why I (or any internet stranger) should?

It is not a good idea for a casual user to begin arbitrarily disabling and removing modifications from a prescribed modpack in an unlikely effort to catch an issue that seems much more likely to be a Java implementation issue or launcher issue. I do not believe that a mod working within the confines of a mod loading library is capable/likely of introducing such a significant issue as preventing the proper clean-up of the game process and the launcher status. Keep in mind that the issue is not only leaving the game process running in the background, but is also leaving the launcher process open and hidden as well.

Well, this is to determine what mod breaks the game only. Why are you looking at Java or launcher as the most direct modifications to the game are made through mods. And believe me, they are capable of something like this.

Also as you mentioned java did you try reproducing this with a different version of Java or do you just presume that between the mods (that are many), the Java (that is official ), and the launcher you are using the launcher is at fault.

I do not expect the issue to be with FTB Chunks as the other modpack that I tested also includes the same version of FTB Chunks and did not reproduce the issue.

It was a guess that you could try(usually that and JEI are the easiest to remove from a modpack without breaking the world you are playing).

I will also mention that the response received comes off as condescending and unhelpful, that as well as unilaterally closing the issue as wontfix without any noted attempt to reproduce is rather rude.

Well I did try to reproduce it but similar to you I was unable to do so with vanilla Minecraft (and I made sure it also included a longer session on my testings)

To clarify, I'm not here for user support. I'm here to report a suspected issue with the launcher that I am experiencing, of which the team responsible for development should be made aware. I am capable of terminating the rogue process myself when the issue occurs. GitHub issues exist to make the developer aware of potential issues with a product that they maintain. Discord is not only too ephemeral for it to be a a reliable store of information, but also more relevant for someone seeking user support for an ongoing minor issue as previously mentioned.

Yeah, you are right but if it is not reproducible without mods then that means it is not the launcher's fault but a mods one.

My impetus for coming directly to this project to report and not to another location is that the launcher is used to spawn the Java process which runs the game, it is the parent process of the Java VM in this case and as such should be responsible for the cleanup of said process if it is not successfully self-terminating.

Prism is responsible for it: it starts it and monitors it to determine if it has crashed or not. But If the process is not terminated prism can't assume on its own that it needs to terminate your game. That's why prism has a kill button near the Launch so that in cases users see that the Minecraft process is not responding(or not terminating) to force close the process.

from prismlauncher.

If you do not have time to devote to your issue why I (or any internet stranger) should?

This is where you post information to inform the maintainers of a project that there is a suspected issue, is it not? You're asking why I would bother to report a suspected bug? That makes you seem rather unserious.

Well, this is to determine what mod breaks the game only. Why are you looking at Java or launcher as the most direct modifications to the game are made through mods. And believe me, they are capable of something like this.

Because, as I explained previously, the game seems to shut down visually just fine, however the JVM remains resident in memory using a significant amount of system resources (whatever was allocated to the game at runtime as well as a more negligible amount of CPU time) as a child process of the Launcher, which is also hidden until it is re-summoned even though it is supposed to re-open on game exit.

Also as you mentioned java did you try reproducing this with a different version of Java or do you just presume that between the mods (that are many), the Java (that is official ), and the launcher you are using the launcher is at fault.

I have not attempted to re-produce the issue with a different version of Java, and frankly that's not my responsibility. I am not a project maintainer, my role here is to report my observation(s) to serve as a notification of a possibly emerging issue. Also, I explicitly mentioned that I am using the OpenJDK runtime packaged by Red Hat as part of the Fedora-based repos, so it is NOT the official Oracle/Sun Microsystems release. As such it is entirely possible that the issue is related to the runtime, which I also previously suggested, had you attempted to read my report thoroughly.

I do not expect the issue to be with FTB Chunks as the other modpack that I tested also includes the same version of FTB Chunks and did not reproduce the issue.

I will re-iterate that I do not believe it is my position to attempt to dissect the issue myself, as for the suggestion that FTB Chunks may be responsible it is understood and appreciated. That being said I am informing you that it is unlikely to be the culprit as it WAS explicitly tested.

I will also mention that the response received comes off as condescending and unhelpful, that as well as unilaterally closing the issue as wontfix without any noted attempt to reproduce is rather rude.

Well I did try to reproduce it but similar to you I was unable to do so with vanilla Minecraft (and I made sure it also included a longer session on my testings)

That's the sort of thing that ought to be notated then, no? Especially if you are going to consecutively decide that the report is no longer worth anyone's time by closing the issue, which reduces it's potential efficacy of notice, keeping in mind that this is a community-driven, collaborative effort.

Prism is responsible for it: it starts it and monitors it to determine if it has crashed or not. But If the process is not terminated prism can't assume on its own that it needs to terminate your game. [...]

This is exactly my point, the process exits visually and interactively, however remains as a background process for hours after the game has seemingly exited successfully. The fact that the launcher does not re-open upon the game closing, as I have set the preferences to, implies that the launcher is having trouble determining that game has come to a close. i.e. A launcher issue.

[...]That's why prism has a kill button near the Launch so that in cases users see that the Minecraft process is not responding(or not terminating) to force close the process.

As previously stated the launcher's Kill option does not function (see EDIT of OP), even when the launcher is manually re-summoned after game close. The launcher, in fact, remains nearly inoperable in this state, which further reinforces the notion that there are underlying issues with the launcher's clean-up and exit process for the managed Java session.

Finally, I would like to request that the issue be re-opened and placed back into investigation. I am still willing to attempt certain actions such as log gathering and reproduction testing should there be a valid explanation for their suggestion. I am not given the option to do this myself, or the change would already have been made. Thank you.

from prismlauncher.

I am not sure if there is anything we can fix here. If the game process is running, and you close the launcher, the launcher will still be running in the background until the game process ends. The launcher can not reliably determine if the game is supposed to be closed, so we can't really change this behavior.

If your Java process is stuck, then this is NOT a launcher issue.

Perhaps we could implement a Force Kill option on Linux systems that kills the JVM using SIGKILL

I will re-iterate that I do not believe it is my position to attempt to dissect the issue myself

You are the only one here who is able to consistently reproduce the issue. If you wish for this to be investigated, then we will need more details from you.

from prismlauncher.

I am not sure if there is anything we can fix here. If the game process is running, and you close the launcher, the launcher will still be running in the background until the game process ends.

Perhaps I did not explain the scenario clearly, I am not closing the launcher. The launcher and console close themselves upon game launch (despite being set to stay open, likely a separate issue). I'm not certain why this happens, but it is not instance dependent.

The launcher can not reliably determine if the game is supposed to be closed, so we can't really change this behavior.

Understood, does that mean the function to re-open the launcher after game exit is only monitoring the Java process lifespan and waiting for it to close autonomously, or is there something more complicated going on? If that is the case, how does the launcher know (to re-open the console) when the game has crashed?

Perhaps we could implement a Force Kill option on Linux systems that kills the JVM using SIGKILL

This is your prerogative, I don't necessarily see this as critical. However, if you do I would suggest maybe first send SIGTERM (as I assume is the current implementation) and if no response, pop a dialog and ask if user wants to send SIGKILL? For reference, SIGKILL is the only method I have found to end the hung Java process successfully, it does not respond to even a manually issued SIGTERM. By this I mean neither the Kill button in launcher nor a manually issued signal have any effect.

I will re-iterate that I do not believe it is my position to attempt to dissect the issue myself

You are the only one here who is able to consistently reproduce the issue. If you wish for this to be investigated, then we will need more details from you.

I understand this and have no problem providing details, as I've stated before I am willing to try to help should I be given a reasonable suggestion. Is there anything in particular you'd like me to try, other than arbitrarily disabling and removing mods from a predefined pack in the hopes that I hit a silver bullet? Even a suggestion as to specific mods to try is somewhat more reasonable and more workable.

from prismlauncher.

I can provide logs if desired as well, but as modded MC tends to generate a LOT of text, I am refraining from simply uploading them all to prevent text spam. They are available upon request.

from prismlauncher.

I can also provide a modlist and config files*, as well as my world file if you suspect it may be relevant should you wish to attempt to reproduce it more closely.

*The mods and config set were manually downloaded and then applied to a clean Forge profile in launcher via MCModpackDL as they are not provided publically by FTB except as a direct download via their proprietary binary. Due to reasons that I'm sure the team is aware of, it may be prudent to provide instructions to recreate the pack the way that I did instead of direct redistribution. I can do that as well should it be desired.

from prismlauncher.