blelogger – terminate called after throwing an instance of 'std::logic_error'

[r-bt]

I've made and installed this library and am attempting to run the blelogger file with:

sudo ./blelogger C6:E7:40:7B:1B:35

I've also modified the blelogger file to change the debug level to

log_level = Debug;

When I try run blelogger it gives the following

info  1689609679.778310 log_fd_: Socket success: 221 (/home/rbeattie/Documents/libblepp/src/blestatemachine.cc)
info  1689609679.778485 log_fd_: Socket success: 266 (/home/rbeattie/Documents/libblepp/src/blestatemachine.cc)
info  1689609679.778586 log_fd_: Socket success: 171 (/home/rbeattie/Documents/libblepp/src/blestatemachine.cc)
info  1689609679.778676 log_l2cap_options: options.omtu = 672
info  1689609679.778754 log_l2cap_options: options.imtu = 672
info  1689609679.778831 log_l2cap_options: options.flush_to = 65535
info  1689609679.778905 log_l2cap_options: options.mode = 0
info  1689609679.778980 log_l2cap_options: options.fcs = 1
info  1689609679.779055 log_l2cap_options: options.max_tx = 3
info  1689609679.779130 log_l2cap_options: options.txwin_size = 63
debug 1689609679.779211 connect: address = c6:e7:40:7b:1b:35
debug 1689609679.779281 connect: str2ba = 0
error 1689609721.673936 log_fd_: Error on line: 293 (/home/rbeattie/Documents/libblepp/src/blestatemachine.cc): Operation now in progress
terminate called after throwing an instance of 'std::logic_error'
  what():  Trying to read socket while connecting
Aborted

I'm getting the address from lescan so I'm sure that the adapter can see it

[edrosten]

any chance you can compile in debug mode and send a stack trace?

[r-bt]

Sure, I'm not sure if this is right (I don't have too much experience with c++) but I recompiled libblepp with cmake -DWITH_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Debug .. and then ran sudo gdb --args ./examples/blelogger f7:aa:cd:dc:21:75 and ran bt once it crashed which gave:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xf7c37364 in __GI_abort () at abort.c:79
#2  0xf7e20f88 in __gnu_cxx::__verbose_terminate_handler() () from /lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0xf7e1eacc in ?? () from /lib/arm-linux-gnueabihf/libstdc++.so.6
#4  0xf7e1eb58 in std::terminate() () from /lib/arm-linux-gnueabihf/libstdc++.so.6
#5  0xf7e1ef28 in __cxa_throw () from /lib/arm-linux-gnueabihf/libstdc++.so.6
#6  0xf7f55f10 in BLEPP::BLEGATTStateMachine::read_and_process_next (this=0xfffef344) at /home/rbeattie/Documents/libblepp/src/blestatemachine.cc:519
#7  0x00011164 in main (argc=<optimized out>, argv=<optimized out>) at examples/blelogger.cc:89

It looks quite short so I might have missed a step to get the proper stacktrace.

From my own debugging I've found that it gets to

int ret = log_fd(::connect(sock, (sockaddr *)&addr, sizeof(addr)));

where it hangs until the function times out. Ret is then equal to -1 indicating an error while errorno is set to EINPROGRESS indicating the connection is still happening. In blelogger it then immediately calls read_and_process_next() which throws if the state is set to Connecting. I tried modifying this so that it wouldn't read while the state was still connecting with

for (;;)
    if (!gatt.wait_on_write())
    {
        gatt.read_and_process_next();
    }

but that just hangs. I'm not sure is there another function I should be calling that checks if state can be changed from Connecting to Idle

[r-bt]

@edrosten not sure if it's relevant but while I was debugging I found https://stackoverflow.com/questions/72451087/how-to-connect-ble-devices-using-linux-bluetooth-c-library which seems to imply that BlueZ's move to DBUS can get in the way of connecting to devices through the old hci_xxx methods

[r-bt]

@edrosten Just as a check I downgraded to bluez 5.48 and 5.42, recompiled libblepp but the issue was still present