meta data for this page
This is an old revision of the document!
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)
THIS ISN'T YET IMPLEMENTED INTO THE CODE
- 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
- WLAN plugin stops at first write error in
WLANPlugin::InquiryThread. There should be at least some tolerance for failures. - julaakko
- Fixed in Maemo with listener, could be solved by creating a listener for WLAN state in Linux.
- 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..).
Genral bugs in code
The function reaches end of non-void function in error situations although it should return a
FIXED - julaakko
Slight problems with Bluetooth
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
Too many open files
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.