Plugin creating two instances #7
Assignees
Labels
bug
Something isn't working
Comments
|
@imsnif Any ideas on what may be causing this? |
|
Does it happen if you give it an absolute path without the |
|
@imsnif Yeah, I'm still seeing it even with an absolute path rather than |
|
Hey yeah - I looked into this a little bit. I think some event ordering changed in the recent version and this plugin was relying on this ordering (my bad!) - a good way to fix this might be to make opening the multitask environment atomic. So that if we did it once, we will never do it again until the plugin is reloaded. Maybe some conditional around here: https://github.com/imsnif/multitask/blob/main/src/main.rs#L64 |
|
@imsnif I gave this a shot and also added some print statements to get some more info. I'm using a diff --git a/src/main.rs b/src/main.rs
index ed353ac..09009bd 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -25,6 +25,7 @@ struct State {
plugin_id: Option<u32>,
shell: String,
cwd: Option<PathBuf>,
+ was_opened: bool,
}
impl ZellijPlugin for State {
@@ -45,6 +46,8 @@ impl ZellijPlugin for State {
Some(s) => Some(PathBuf::from(s)),
_ => None
};
+ eprintln!{"RUNNING LOAD for ID {}", self.plugin_id.unwrap()};
+ eprintln!{"Zellij PID: {}",get_plugin_ids().zellij_pid}
show_self(true);
}
@@ -61,7 +64,14 @@ impl ZellijPlugin for State {
// we clean up our state and start over, allowing the plugin to be triggered by
// a keybinding
hide_self();
- self.start_multitask_env();
+ eprintln!{"RUNNING PANE UPDATE for ID {}", self.plugin_id.unwrap()};
+ eprintln!{"Status of was opened: {}", self.was_opened};
+ if !self.was_opened
+ {
+ self.was_opened = true;
+ eprintln!{"Status of was opened: {}", self.was_opened};
+ self.start_multitask_env();
+ }
} else if let Some(running_tasks) = &mut self.running_tasks {
running_tasks.update_task_status(&pane_manifest);
if running_tasks.all_tasks_completed_successfully() {However, I'm still seeing the same issue. I checked the log to see the status of my print statements: It looks like the call to
One other interesting thing to note. If I use |
|
@imsnif I compiled zellij from GitHub using the devel instructions so I could start to dump stack traces and try to figure out why the plugin was being loaded twice. I'm very unfamiliar with the internals of zellij, so I'm doing some speculating in the paragraphs that follow: please take it all with a huge grain of salt. I also have the stack traces from the zellij log at the end if you're interested. The It looks like Click to expand the full stack traceCurrent git diff to re-create this stack trace if desireddiff --git a/zellij-server/src/lib.rs b/zellij-server/src/lib.rs
index 51daeb0e..1f6f57e2 100644
--- a/zellij-server/src/lib.rs
+++ b/zellij-server/src/lib.rs
@@ -15,6 +15,7 @@ mod terminal_bytes;
mod thread_bus;
mod ui;
+use std::backtrace::Backtrace;
use background_jobs::{background_jobs_main, BackgroundJob};
use log::info;
use pty_writer::{pty_writer_main, PtyWriteInstruction};
@@ -916,6 +917,7 @@ fn init_session(
#[cfg(not(feature = "singlepass"))]
fn get_store() -> Store {
use wasmer::{BaseTunables, Cranelift, Engine, Pages, Target};
+ log::info!("Backtrace from get_store: {}", Backtrace::force_capture());
log::info!("Compiling plugins using Cranelift");
// workaround for https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8
diff --git a/zellij-server/src/plugins/wasm_bridge.rs b/zellij-server/src/plugins/wasm_bridge.rs
index bb58d611..badc8893 100644
--- a/zellij-server/src/plugins/wasm_bridge.rs
+++ b/zellij-server/src/plugins/wasm_bridge.rs
@@ -1,3 +1,4 @@
+use std::backtrace::Backtrace;
use super::{PluginId, PluginInstruction};
use crate::plugins::plugin_loader::PluginLoader;
use crate::plugins::plugin_map::{AtomicEvent, PluginEnv, PluginMap, RunningPlugin, Subscriptions};
@@ -119,6 +120,7 @@ impl WasmBridge {
// returns the plugin id
let err_context = move || format!("failed to load plugin");
+ log::info!("Backtrace from load_plugin in WASM bridge: {}", Backtrace::force_capture());
let client_id = client_id
.or_else(|| {
self.connected_clients
diff --git a/zellij-tile/src/lib.rs b/zellij-tile/src/lib.rs
index 39058c29..1c18042d 100644
--- a/zellij-tile/src/lib.rs
+++ b/zellij-tile/src/lib.rs
@@ -112,11 +112,13 @@ macro_rules! register_plugin {
use std::convert::TryInto;
use zellij_tile::shim::plugin_api::action::ProtobufPluginConfiguration;
use zellij_tile::shim::prost::Message;
+ use std::backtrace::Backtrace;
let protobuf_bytes: Vec<u8> = $crate::shim::object_from_stdin().unwrap();
let protobuf_configuration: ProtobufPluginConfiguration =
ProtobufPluginConfiguration::decode(protobuf_bytes.as_slice()).unwrap();
let plugin_configuration: BTreeMap<String, String> =
BTreeMap::try_from(&protobuf_configuration).unwrap();
+ eprintln!("Plugin load backtrace: {}", Backtrace::force_capture());
state.borrow_mut().load(plugin_configuration);
});
}
diff --git a/zellij-utils/src/plugin_api/action.rs b/zellij-utils/src/plugin_api/action.rs
index dc8c2938..f1637cca 100644
--- a/zellij-utils/src/plugin_api/action.rs
+++ b/zellij-utils/src/plugin_api/action.rs
@@ -1,3 +1,4 @@
+use std::backtrace::Backtrace;
pub use super::generated_api::api::{
action::{
action::OptionalPayload, Action as ProtobufAction, ActionName as ProtobufActionName,
@@ -403,6 +404,8 @@ impl TryFrom<ProtobufAction> for Action {
let should_float = payload.should_float;
let move_to_focused_tab = payload.move_to_focused_tab;
let should_open_in_place = payload.should_open_in_place;
+ // or forcibly capture the backtrace regardless of environment variable configuration
+ eprintln!("Backtrace from LaunchOrFocusPlugin action: {}", Backtrace::force_capture());
Ok(Action::LaunchOrFocusPlugin(
run_plugin,
should_float,EDIT: Also including stack trace from Log info with stack trace for start or reload pluginAfter looking through these stack traces again, the one from start or reload calls Did some more printing and looking at logs today. When reloading a plugin, Trying to trace where this comes from: It looks like Put some prints in Coming from the other side (CLI) I see |
|
@imsnif Just sending a gentle reminder for the message above. I'm curious if this could be something in the |
|
Hey, I'm really sorry for taking so long to get to this. As always, I'm incredibly swamped and don't have enough resources to deal with everything that needs to be dealt with in Zellij. I hope to get to this soon. If you'd like to do some debugging with Zellij itself and find out what's happening, that would be great. I realize this is a tall order though. So if you'd rather wait for me, I can only ask you for your patience and thank you for your consistency. I have not forgotten you, I'm however only one person :/ |
|
@imsnif No sweat at all. Just wanted to send a reminder, since I know it's easy for stuff to get buried. Thanks again for all the amazing work you do with I'm a bit swamped at work as well (so have had less time for this than I'd like). I can try to do some debugging if I get some spare time over the next few weeks, but would appreciate any help you can provide whenever you have the chance (no rush). |
|
@imsnif Okay, I figured out what is happening, but am not sure of the correct fix. Again, no rush on this, just wanted to put this message here as a nice summary whenever you get around to it (so you don't have to read through my rambling in the full comment).
I'm not familiar enough with the
Click to expand the git diffdiff --git a/zellij-server/src/plugins/mod.rs b/zellij-server/src/plugins/mod.rs
index 2086268d..eb2c2300 100644
--- a/zellij-server/src/plugins/mod.rs
+++ b/zellij-server/src/plugins/mod.rs
@@ -184,7 +184,11 @@ pub(crate) fn plugin_thread_main(
client_id,
size,
cwd,
- ) => match wasm_bridge.load_plugin(&run, tab_index, size, cwd.clone(), Some(client_id))
+ // The client ID is from the calling action, e.g., zellij action
+ // launch-or-focus-plugin. Hence, we do not want to actually load the plugin
+ // for that client_id. As a result, we pass in None, since that will use
+ // the first connected client as the client_id.
+ ) => match wasm_bridge.load_plugin(&run, tab_index, size, cwd.clone(), None)
{
Ok(plugin_id) => {
drop(bus.senders.send_to_screen(ScreenInstruction::AddPlugin(
|
|
@imsnif Just sending a gentle reminder so this doesn't get lost. No rush, on it as I know you are very busy. In the comment above I believe I've identified the issue and have a proposed fix to the Zellij core. If you like the proposed fix let me know and I'll submit it as a PR on the Zellij core. |
|
A recent commit on the
|
|
I am very happy to hear this @leakec - and you have my sincerest apologies for ignoring this issue for so long. I was honestly meaning to take a deeper look at it in the next week or two. Thanks for all your hard work and for your patience! |
|
No sweat @imsnif. I know you're super busy, and thank you for all you do for this amazing tool! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To re-create this issue:
Then run
twice. The first time everything should work as intended. The second time and all subsequent times, two instances of the multitask file will open in two different panes, i.e., two instances of the plugin are running. This persists even if I close and re-open a new
zellijsession.If I clear the
~/.cache/zellijfolder, then the plugin works as intended the first time I re-run it, but again opens two instances afterward.This is a new issue I'm only seeing with
zellij 0.39.0.The text was updated successfully, but these errors were encountered: