Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck permanently waiting when trying to discover characteristics for peripheral #38

Open
visceralfield opened this issue Jun 25, 2019 · 1 comment

Comments

@visceralfield
Copy link

visceralfield commented Jun 25, 2019

Using code equivalent to the example file, with the change described in #30 in order to allow connection to be successful. When the code reaches the point of attempting to discover characteristics, it hangs in wait_until_done permanently. The backtrace from GDB is as follows:

`PERIPHERAL:

EA:BC:02:5E:A6:C6 properties: PeripheralProperties { address: EA:BC:02:5E:A6:C6, address_type: Random, local_name: Some("LOCK-INIT"), tx_power_level: None, manufacturer_data: Some([2, 162, 255, 255, 255, 253, 5, 71, 147, 2, 0, 0, 0, 205, 4]), discovery_count: 16, has_scan_response: false }, characteristics: {}
[New Thread 0x769ff400 (LWP 14289)]

Trying to discover characteristics...

^C
Thread 1 "hello_world" received signal SIGINT, Interrupt.
0x76f719a4 in __pthread_cond_wait (cond=0x51fe28, mutex=0x51fe08) at pthread_cond_wait.c:188
188 pthread_cond_wait.c: No such file or directory.
(gdb) bt
#0 0x76f719a4 in __pthread_cond_wait (cond=0x51fe28, mutex=0x51fe08) at pthread_cond_wait.c:188
#1 0x00460784 in std::sys::unix::condvar::Condvar::wait::hd4783c7e53c7894c (self=0x51fe28, mutex=0x51fe08)
at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/sys/unix/condvar.rs:69
#2 0x004236cc in std::sys_common::condvar::Condvar::wait::h1834f96141448671 (self=0x51fe28, mutex=0x51fe08)
at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/sys_common/condvar.rs:41
#3 0x00459228 in std::sync::condvar::Condvar::wait::hb2f047c82f3cfd71 (self=0x51fe90, guard=...)
at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/sync/condvar.rs:204
#4 0x0047bb74 in rumble::bluez::adapter::peripheral::Peripheral::wait_until_done::h02e167200bfd64a3 (operation=...)
at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:289
#5 0x0047b848 in rumble::bluez::adapter::peripheral::Peripheral::request_raw::he3462da61a8e24b0 (self=0x7efff168, data=...)
at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:208
#6 0x0047e048 in _$LT$rumble..bluez..adapter..peripheral..Peripheral$u20$as$u20$rumble..api..Peripheral$GT$::discover_characteristics_in_range::h5b974183dd98d25e (self=0x7efff168, start=1, end=65535)
at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:454
#7 0x0047dd64 in $LT$rumble..bluez..adapter..peripheral..Peripheral$u20$as$u20$rumble..api..Peripheral$GT$::discover_characteristics::h156ac34c88075480 (self=0x7efff168)
at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:444
#8 0x00407240 in hello_world::main::h84896516970ce619 () at src/main.rs:46
#9 0x00408e08 in std::rt::lang_start::
$u7b$$u7b$closure$u7d$$u7d$::h0a710e18e571eb65 ()
at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/rt.rs:64
#10 0x004df3e4 in {{closure}} () at src/libstd/rt.rs:49
#11 do_call<closure,i32> () at src/libstd/panicking.rs:293
#12 0x004e2678 in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:87
#13 0x004dfe38 in try<i32,closure> () at src/libstd/panicking.rs:272
#14 catch_unwind<closure,i32> () at src/libstd/panic.rs:388
#15 lang_start_internal () at src/libstd/rt.rs:48
#16 0x00408dd8 in std::rt::lang_start::h14f3dad8e1b8c801 (main=0x406d70 <hello_world::main::h84896516970ce619>, argc=1,
argv=0x7efff764) at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/rt.rs:64
#17 0x00407648 in main ()
`

This library looks really promising, I would love to hear back on this about how a fix may be possible. Info on vars in the most relevant frames is follows, I can capture more debug output on request,
including output from my peripheral, which currently outputs nothing of relevance during the wait.

(gdb) frame 4 #4 0x0047bb74 in rumble::bluez::adapter::peripheral::Peripheral::wait_until_done::h02e167200bfd64a3 (operation=...) at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:289 289 done = cvar.wait(done).unwrap(); (gdb) locals Undefined command: "locals". Try "help". (gdb) info locals done = std::sync::mutex::MutexGuard<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>> {__lock: 0x51fe68, __poison: std::sys_common::poison::Guard {panicking: false}} lock = 0x51fe68 cvar = 0x51fe90 on_finish = 0x51fea0 pair2 = alloc::sync::Arc<(std::sync::mutex::Mutex<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>>, std::sync::condvar::Condvar)> {ptr: core::ptr::NonNull<alloc::sync::ArcInner<(std::sync::mutex::Mutex<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>>, std::sync::condvar::Condvar)>> {pointer: 0x51fe60}, phantom: core::marker::PhantomData<(std::sync::mutex::Mutex<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>>, std::sync::condvar::Condvar)>} pair = alloc::sync::Arc<(std::sync::mutex::Mutex<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>>, std::sync::condvar::Condvar)> {ptr: core::ptr::NonNull<alloc::sync::ArcInner<(std::sync::mutex::Mutex<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>>, std::sync::condvar::Condvar)>> {pointer: 0x51fe60}, phantom: core::marker::PhantomData<(std::sync::mutex::Mutex<core::option::Option<core::result::Result<alloc::vec::Vec<u8>, rumble::Error>>>, std::sync::condvar::Condvar)>} (gdb) frame 6 #6 0x0047e048 in _$LT$rumble..bluez..adapter..peripheral..Peripheral$u20$as$u20$rumble..api..Peripheral$GT$::discover_characteristics_in_range::h5b974183dd98d25e (self=0x7efff168, start=1, end=65535) at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:454 454 let data = self.request_raw(&mut buf)?; (gdb) info locals buf = alloc::vec::Vec<u8> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::Unique<u8> {pointer: 0x51fb28 "\b\001\000", _marker: core::marker::PhantomData<u8>}, cap: 7, a: alloc::alloc::Global}, len: 7} start = 1 results = alloc::vec::Vec<rumble::api::Characteristic> {buf: alloc::raw_vec::RawVec<rumble::api::Characteristic, alloc::alloc::Global> {ptr: core::ptr::Unique<rumble::api::Characteristic> {pointer: 0x2, _marker: core::marker::PhantomData<rumble::api::Characteristic>}, cap: 0, a: alloc::alloc::Global}, len: 0} (gdb) frame 7 #7 0x0047dd64 in _$LT$rumble..bluez..adapter..peripheral..Peripheral$u20$as$u20$rumble..api..Peripheral$GT$::discover_characteristics::h156ac34c88075480 (self=0x7efff168) at /home/josh/.cargo/git/checkouts/rumble-909815939d4a9900/3117372/src/bluez/adapter/peripheral.rs:444 444 self.discover_characteristics_in_range(0x0001, 0xFFFF) (gdb) info locals No locals.

@felsweg
Copy link

felsweg commented Sep 27, 2019

I experienced the same problem, but only after initial discovery and bindings. You could store them, if that helps. I experience a similar problem, when reusing characteristics. The second time I try to use them (eg. sending a command), seems not to work. I haven't been looked into this issue more deeply, yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants