Solutions for PeerHood Problems

See development changes procedure.

PeerHood did reserve vast amount of (virtual) memory when started, ~21 MB with bluetooth plugin only (~44 MB when using WLAN and bluetooth) when only the daemon was running. The testing of memory consumption was performed for this reason to find out what uses or reserves that memory. First test and second test indicated that the memory was only reserved for some purpose while only small portion of it was used. With third test the reason was found: pthread library does reserve a big memory space for each thread when thread is started, the size of the memory space is the same as the default stack size in operating system (see testing)

Solution to this was to reduce the stack size, it can be done by setting a stack size for each thread in program code. See solution on the memory analysis pages.

THIS ISN'T YET IMPLEMENTED INTO THE CODE

1. If plugin exists and it is loaded PeerHood daemon segfaults if there is no specified WLAN-interface up and running. This happens only when starting the daemon. - julaakko
2. WLAN plugin stops at first write error in WLANPlugin::InquiryThread. There should be at least some tolerance for failures. - julaakko

1. Fixed in Maemo with listener, could be solved by creating a listener for WLAN state in Linux.
2. Increased the tolerance to 10, defined in the WLANPlugin.cc. Plugin stops when amount of errors is reached, when there are same amount of successful writes the counter for errorous writes is zeroed. This is just a temporary solution, the plugin doesn't crash when e.g changing network (tolerance can be increased, it should be defined in config..).

The function reaches end of non-void function in error situations although it should return a boolean-value.

FIXED - julaakko

Briefly: after PeerHood daemon (alone, no services or applications using the daemon) has been running for ~7 hours or more it either crashes (segfault or in latest tests assertion error in CBTConnection line 40) or starts reporting -1 responses from surrounding bluetooth devices and also errors reported by BTPlugin::Inquirythread :

Too many open files

and

Device or resource busy

First could be result from hci_inquiry -function functionality, second could be from thread safety issue in BlueZ bluetooth library. For further information, see: a possible feature found in Bluetooth library/hardware functionality - incl. testing.

Copied the inquiry-function from hci.h and modified it not to open new socket on every inquiry. Currently PeerHood uses a raw socket to bluetooth device to control it via ioctl commands, currently only inquiry and adapter reset are using this. New socket is created when the bluetooth plugin is loaded. This reduces the errors mentioned in the problem description, there still exists some faulty socket/handle usages which at some point can cause “Too many open files” error.