Rustrover crashes after running program when launched from bemenu

[bumblepie]

When I start rustrover via bemenu, after trying to run the project itself in the IDE, rustrover immediately exits. I have raised an issue with rustrover itself (see below), however I have noticed that the behaviour only occurs when using bemenu-run: if I run rustrover directly from the terminal or from fuzzel, it does not exit. Because of this, I'm not really sure if the issue is on the bemenu side or the rustrover side, my suspicion is that it's a weird intersection of the two. I also couldn't see where to find any logs from bemenu-run to help diagnose the issue. Are you able to provide any clarifying info as to how bemenu-run actually executes the selected result? Thanks for your time

https://youtrack.jetbrains.com/issue/RUST-12631/IDE-exits-immediately-after-running-project

[Cloudef]

https://github.com/Cloudef/bemenu/blob/master/client/bemenu-run.c#L139-L152
The launching method is here, I suspect the program doesn't like that we close stdout and stdin?

[bumblepie]

Built from source, was able to reproduce the issue. I then commented out the lines which close stdout/stdin as indicated (140-144), and that change seems to fix the issue - rustrover is able to run the project without immediately exiting.

However, I tried to narrow it down further by running rustrover from the command line and redirecting stdout/stdin to dev null: rustrover-eap &>/dev/null, and this method did not face the exiting issue. Because of this, I tried commenting out only line 141 (setsid()), and this version works as well - it seems like setsid() is the cause of the issue! COnfirmed this by running setsid rustrover in the terminal, and observed the problematic behaviour

It's been a while since I went over process forking etc, so I'm not really clear on how it all works, but potentially this is interacting in a weird way with whatever method rustrover uses to make child processes to run a project

[bumblepie]

Did some further experiments and was able to confirm that hardcoding client-> fork to false prevents the behaviour. I'm not 100% clear, what is forking being used to achieve in this case? Would it be reasonable to add an override similar to the existing --fork that disables forking instead, or would that introduce problems?

[Cloudef]

Exec without fork replaces the current process, so no new PID is given. It's interesting setsid() would affect rustrover, it feels like bemenu is just exposing a bug in the chain, or there's some env variables that are not carried all the way to the other process.

[bumblepie]

Hmm, definitely agree that it's more likely that this happens to expose a bug in rustrover rather than a bug per se in bemenu. Unfortunately, due to the fact there are workarounds and the nature of the issue, it looks like it's unlikely to get much traction in order to get fixed on the rustrover side.

I can see why forking might be required pid-wise, does the setsid call specifically have a use? Took a look at fuzzel for reference and I can see a similar pattern of forking, closing stdout/in but without the setsid call. Would it be possible to have a command-line option to disable the setsid call?

Thanks again, I really appreciate your time responding to this as I understand it's not really a bemenu issue and it's hyper-specific to my use-case.