C code "crashes"...

Lost User

Could somebody kindly help me to identify the problem with this code. It is basically original C code I am trying to annotate. I have included all what I can find about the

hci_devba

function. I have no better error description - the app just crashes executing the function. I am confident the "dev_id" ( function descriptor ?) is valid - the app runs just fine when function

hci_devba

is bypassed. I am not certain I am using the

bdaddr_t *bdaddr

parameter correctly.

hci_get_route(NULL);

uses same (address stricture) parameter, but passing it as NULL results in "selecting any (default) local devices ". Appreciate any help. Thanks.

    dev\_id = hci\_get\_route(NULL);

#ifdef BYPASS
// common bluetooth address
int hci_devba(int dev_id, bdaddr_t *bdaddr);
typedef struct {
uint8_t b[6];
} __attribute__((packed)) bdaddr_t;

                int hci\_devba(int dev\_id, bdaddr\_t \*bdaddr)
                {
                    struct hci\_dev\_info di;
                
                    memset(&di, 0, sizeof(di));
                
                    if (hci\_devinfo(dev\_id, &di))
                        return -1;
                
                    if (!hci\_test\_bit(HCI\_UP, &di.flags)) {
                        errno = ENETDOWN;
                        return -1;
                    }
                
                    bacpy(bdaddr, &di.bdaddr);
                
                    return 0;
                }

#endif
bdaddr_t *bdaddr_1 = NULL;
result = hci_devba(dev_id,bdaddr_1);

Victor Nijegorodov

Did you try to debug our code?

k5054

Digging around it seems that bacpy is defined in bluetooth.h as

static inline void bacpy(bdaddr_t *dst, const bdaddr_t *src)
{
memcpy(dst, src, sizeof(bdaddr_t));
}

The C standard says that if the destination address for memcpy is null, then the results are undefined. It looks like the GNU libc implementation causes a seg-fault in this case. Other libraries may do something different. My take is that wherever you got your documentation for hci_devba(), it is mistaken about passing a NULL pointer to hci_devba for the bdaddr parameter.

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

Lost User

Got caught by "bluez" library...and I will leave it alone... Apparently "hci_devba" does not "return" device address and crashes when "dev_id" is passed to it. When "socket" is build using

sock = hci_open_dev( dev_id );

it makes little sense ( to me) to pass "socket" to

hci_devba

BUT at least it does not crash...

    bdaddr\_t \*bdaddr\_1={0};

   result = hci\_devba(**sock**, bdaddr\_1);
   if(result == 0)
   {
       text = "SUCCESs local device address ";
       //CONVERT char to string
       ba2str(bdaddr\_1, addr);
       text = addr;
   }
   else
   {
       text = "FAILED to get local device address (socket) ";
   }
   qDebug()<< text;

PS I do not get why your definition ) of

hci_devba

and mine do not match.

k5054

My "definition" of hci_devba (e.g. hci_devba()) was only meant to convey that the "object" referred to was a "function", and not meant to be a full "prototype" for same.

Salvatore Terress wrote:

it makes little sense ( to me) to pass "socket" to

I can only assume that's the requirement of the function, as written by its author. It's no more mysterious than requiring a file descriptor when calling read() or write() (n.b. those are just indications that read() and write() are functions, and not some other object type ... )

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

Lost User

I have verified that the first parameter is indeed "dev_id" , unfortunately "bluez" does not brother to farther identify it . I "assume" it is "file descriptor"... Since I cannot identify what causes the run to crash I am going to cheat, for now , and use "hcitool dev" to identify the local Bluetooth device. I may get ambitious and find the source for "hcitool" and verify what somebody else coded to identify local device , and its address... cheers