Crash when running Put and Get of simple_key_value_store

[Fraser999]

On Windows, I ran the simple_key_value_store example. There was no network to connect to, and I retried with my machine's network cards disabled to be sure.

On starting the example with no args, no indication is given whether or not it has connected to a network.

If I subsequently tried to Put or Get, the example crashed with output:

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value'

[benjaminbollen]

can we have a line number and a file where this option is unwrapped?

[benjaminbollen]

I'm not aware of remaining .unwrap in the code, but I'm not sure either

[maqi]

vault test : lib_test and executable_test proved there is no network connection get established among routing_nodes.

[benjaminbollen]

true. they aren't currently on 0.1.62

[maqi]

if you look at this line : https://github.com/maidsafe/routing/blob/master/src/routing_node.rs#L165
this is a blocking call, and once you call it, the process won't be able to answer incoming request, which is a deadlock.
that's why the previous code having a separate run() method using try_recv which is non-blocking.

I am afraid this might be the reason why there is no connection got established.

[Fraser999]

@benjaminbollen I deliberately omitted the line no/file since they're useless. Anyway - it's src\libcore\option.rs:362.

The backtrace is also useless (at least on Windows).

[Viv-Rajkumar]

Currently depends on #330 getting resolved first to progress further and assert if further work is needed to resolve this issue.

[Fraser999]

@benjaminbollen There are still a few unwrap()s in the library code outside of the tests.

[inetic]

If one calls the get command on command line, the unwrap happens in the RoutingClient::get function:

pub fn get(&mut self, type_id: u64, name: NameType) -> Result<MessageId, IoError> {
    let requester = types::SourceAddress {
        from_node: self.bootstrap_address.0.clone().unwrap(),  // <------- HERE
        from_group: None,
        reply_to: None,
    ...

[benjaminbollen]

#330 is resolved (not yet merged); so there is a network. I am currently examining if -or why not -a client would not be bootstrapping similarly to the starting node.

[benjaminbollen]

@maqi : only the routing nodes have the internal loop with blocking .recv, instead of .try_recv; it is a good call, but for client this should not be an issue as client still has run { ... .try_recv }

[benjaminbollen]

assigned @inetic as high-five assigned him as reviewer for the PR

[benjaminbollen]

merged