Heisenbug: trip _gateway panic sometimes

[crrodriguez]

#trip _gateway
thread 'main' panicked at /rustc/3cdd004e55c869faa2b7b25efd3becf50346e7d6/library/core/src/cmp.rs:879:9:
assertion failed: min <= max
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Unfortunately it cannot be reproduced the second time ..it happens once in a while.. I'l trry to get a backtrace ..

[fujiapple852]

Thanks for reporting @crrodriguez.

please also try enabling verbose logging with -v which may help give more context around the failure.

To help narrow it down:

Does it happen immediately at startup or during the trace? Does it only happy with the Tui or can you reproduce with -m stream ?

Please also confirm the version of Trippy and your platform.

[fujiapple852]

The assertion failure line from the reported error is from the clamp function:

https://github.com/rust-lang/rust/blob/3cdd004e55c869faa2b7b25efd3becf50346e7d6/library/core/src/cmp.rs#L879

The only place clamp is called (directly, at least) is here:

trippy/src/frontend/render/table.rs

Line 254 in c65a57e

let count = hop.addr_count().clamp(1, max_addr as usize);

[fujiapple852]

@crrodriguez I can reproduce this failure by pressing } (default binding for expand-hosts-max), can you confirm this is what you are doing when it fails?

The bug here is in the TuiApp::max_hosts function:

trippy/src/frontend/tui_app.rs

Lines 388 to 398 in c65a57e

	/// The maximum number of hosts per hop for the currently selected trace.
	pub fn max_hosts(&self) -> u8 {
	self.selected_tracer_data
	.hops(self.selected_flow)
	.iter()
	.map(|h| h.addrs().count())
	.max()
	.and_then(|i| u8::try_from(i).ok())
	.unwrap_or_default()
	}
	}

If there are no hops reported or none of the reported hops contain any addresses, then the function returns 0 (i.e. u8::default() from unwrap_or_default()). This will cause TuiApp::expand_hosts_max to set max_addrs as Some(0):

trippy/src/frontend/tui_app.rs

Lines 380 to 382 in c65a57e

	pub fn expand_hosts_max(&mut self) {
	self.tui_config.max_addrs = Some(self.max_hosts());
	}

With that in place, we will now get a call to clamp(1, 0) which will lead to the assertion failure observed:

trippy/src/frontend/render/table.rs

Line 254 in c65a57e

let count = hop.addr_count().clamp(1, max_addr as usize);

The fix is to ensure that in such cases max_addrs is set to be None.

Given you are running trip _gateway i'm assuming that means _gateway is the first (and only) hop and so it would seem likely that if the _gateway hop does not respond to the IMCP probe then we would indeed end up in a situation where none of the hops contain any addresses and would therefore lead to this bug.

[fujiapple852]

Fixed in #893 which will go into the 0.10.0 release.

[crrodriguez]

@crrodriguez I can reproduce this failure by pressing } (default binding for expand-hosts-max), can you confirm this is what you are doing when it fails?

Yes, See in my spanish language keyboard that key is annoyingly too close to enter and sometimes both get pressed..

I updated to https://github.com/fujiapple852/trippy.git#58dc9b58) and the problem still there. I 'll try your fix.
Thanks.

[c-git]

Thank you very much for testing and confirming that works @crrodriguez

[fujiapple852]

I merged #893 so you can retry from the latest master (f07d58f) if you wish.

[crrodriguez]

I merged #893 so you can retry from the latest master (f07d58f) if you wish.

, I did try it and the issue is gone. thanks.!