No abstract

This article presents a tool for uncovering bugs due to interactive complexity in networked sensing applications. Such bugs are not localized to one component that is faulty, but rather result from complex and unexpected interactions between multiple often individually non-faulty components. Moreover, the manifestations of these bugs are often not repeatable, making them particularly hard to find, as the particular sequence of events that invokes the bug may not be easy to reconstruct. Because of the distributed nature of failure scenarios, our tool looks for sequences of events that may be responsible for faulty behavior, as opposed to localized bugs such as a bad pointer in a module. We identified several challenges in applying discriminative sequence mining for root cause analysis when the system fails to perform as expected and presented our solutions to those challenges. We also presented two alternatives schemes, namely, two stage mining and the progressive discriminative sequence mining to address the scalability challenge. An extensible framework is developed where a front-end collects runtime data logs of the system being debugged and an offline back-end uses frequent discriminative pattern mining to uncover likely causes of failure. We provided three case studies where we applied our tool successfully to troubleshoot the cause of the problem. We uncovered a kernel-level race condition bug in the LiteOS operating system and a protocol design bug in the directed diffusion protocol. We also presented a case study of debugging a multichannel MAC protocol that was found to exhibit corner cases of poor performance (worse than single channel MAC). The tool helped uncover event sequences that lead to a highly degraded mode of operation. Fixing the problem significantly improved the performance of the protocol. Finally, we provided a detailed analysis of tool overhead in terms of memory requirements and impact on the running application.

No abstract

While deployment and practical on-site testing remains the ultimate touchstone for sensor network code, good simulation tools can help curtail in-field troubleshooting time. Unfortunately, current simulators are successful only at evaluating system performance and exposing manifestations of errors. They are not designed to diagnose the root cause of the exposed anomalous behavior. This paper presents a diagnostic simulator , implemented as an extension to TOSSIM [6]. It (i) allows the user to ask questions such as "why is (some specific) bad behavior occurring?", and (ii) conjectures on possible causes of the user-specified behavior when it is encountered during simulation. The simulator works by logging event sequences and states produced in a regular simulation run. It then uses sequence extraction, and frequent pattern analysis techniques to recognize sequences and states that are possible root causes of the user-defined undesirable behavior. To evaluate the effectiveness of the tool, we have implemented the directed diffusion protocol and used our tool during the development process. During this process the tool was able to uncover two design bugs that were not addressed in the original protocol. The manifestation of these two bugs were same but the causes of failure were completely different -one was triggered by node reboot and the other was triggered by an overflow of timestamps generated by the local clock. The case study demonstrates a success scenario for diagnostic simulation.

Password managers, though commonly recommended by security experts, are still not used by many users. Understanding why some choose to use password managers while others do not is important towards generally understanding why some users do what they do and, by extension, designing motivational tools such as video tutorials to help motivate more to use password managers. To investigate differences between those who do and do not use a password manager, for this paper, we distributed an online survey to a total of 137 users and 111 non-users of the tool that asked about their opinions/experiences with password managers. Furthermore, since emotion has been identified by work in psychology and communications as influential in other risk-laden decision-making (e.g., safe-sex behavior such as condom use), we asked participants who use a password manager to rate how they feel for 45 different emotions, or, as the case for those who do not use a password manager, to rate how they imagine they would feel the 45 emotions if they did use the tool. Our results show that “users” of password managers noted convenience and usefulness as the main reasons behind using the tool, rather than security gains, underscoring the fact that even a large portion of users of the tool are not considering security as the primary benefit while making the decision. On the other hand, “non-users” noted security concerns as the main reason for not using a password manager, highlighting the prevalence of suspicion arising from lack of understanding of the technology itself. Finally, analysis of the differences in emotions between “users” and “non-users” reveals that participants who never use a password manager are more likely to feel suspicious compared to “users,” which could be due to misunderstandings about the tool.