Oops! Where Did That Code Snippet Come From?

International audienceA kernel oops is an error report that logs the status of the Linux kernel at the time of a crash. Such a report can provide valuable first-hand information for a Linux kernel maintainer to conduct postmortem debugging. Recently, a repository has been created that systematically collects kernel oopses from Linux users. However, debugging based on only the information in a kernel oops is difficult. We consider the initial problem of finding the offending line, i.e., the line of source code that incurs the crash. For this, we propose a novel algorithm based on approximate sequence matching, as used in bioinformatics, to automatically pinpoint the offending line based on information about nearby machine-code instructions, as found in a kernel oops. Our algorithm achieves 92% accuracy compared to 26% for the traditional approach of using only the oops instruction pointer

"Бегство от свободы" советских бэбибумеров: представления о социальном и экономическом благополучии послевоенного поколения в СССР

Исторические и социокультурные исследования бэбибумеров - первого послевоенного поколения - не теряют своей актуальности. В статье анализируются представления о социальном и экономическом благополучии послевоенного поколения в СССР сквозь призму трансформаций потребительских идеалов, социалистических ценностей, представлений о престижных видах деятельности и социальном статусе. Источниковую базу исследования составили материалы советской художественной кинематографии, позволяющие проследить исторически обусловленные различия социального протеста бэбибумеров в западноевропейских странах и в СССР

Large expert-curated database for benchmarking document similarity detection in biomedical literature search

Document recommendation systems for locating relevant literature have mostly relied on methods developed a decade ago. This is largely due to the lack of a large offline gold-standard benchmark of relevant documents that cover a variety of research fields such that newly developed literature search techniques can be compared, improved and translated into practice. To overcome this bottleneck, we have established the RElevant LIterature SearcH consortium consisting of more than 1500 scientists from 84 countries, who have collectively annotated the relevance of over 180 000 PubMed-listed articles with regard to their respective seed (input) article/s. The majority of annotations were contributed by highly experienced, original authors of the seed articles. The collected data cover 76% of all unique PubMed Medical Subject Headings descriptors. No systematic biases were observed across different experience levels, research fields or time spent on annotations. More importantly, annotations of the same document pairs contributed by different scientists were highly concordant. We further show that the three representative baseline methods used to generate recommended articles for evaluation (Okapi Best Matching 25, Term Frequency-Inverse Document Frequency and PubMed Related Articles) had similar overall performances. Additionally, we found that these methods each tend to produce distinct collections of recommended articles, suggesting that a hybrid method may be required to completely capture all relevant articles. The established database server located at https://relishdb.ict.griffith.edu.au is freely available for the downloading of annotation data and the blind testing of new methods. We expect that this benchmark will be useful for stimulating the development of new powerful techniques for title and title/abstract-based search engines for relevant articles in biomedical research.Peer reviewe

Pinpoint the Offending Code in a Kernel Oops

National audienc

Aider le mainteneur d'applications libres à répondre aux rapports d'erreur

When a failure occurs in the Linux kernel, the kernel emits an error report called “kernel oops”, summarizing the execution context of the failure. Kernel oopses describe real Linux errors, and thus can help prioritize debugging efforts and motivate the design of tools to improve the reliability of Linux code. Nevertheless, the information is only meaningful if it is representative and can be interpreted correctly. In this thesis, we study a collection of kernel oopses over a period of 8 months from a repository that is maintained by Red Hat. We consider the overall features of the data, the degree to which the data reflects other information about Linux, and the interpretation of features that may be relevant to reliability. We find that the data correlates well with other information about Linux, but that it suffers from duplicate and missing information. We furthermore identify some potential pitfalls in studying features such as the sources of common faults and common failing applications. Furthermore, a kernel oops provides valuable first-hand information for a Linux kernel maintainer to conduct postmortem debugging, since it logs the status of the Linux kernel at the time of a crash. However, debugging based on only the information in a kernel oops is difficult. To help developers with debugging, we devised a solution to derive the offending line from a kernel oops, i.e., the line of source code that incurs the crash. For this, we propose a novel algorithm based on approximate sequence matching, as used in bioinformatics, to automatically pinpoint the offending line based on information about nearby machine-code instructions, as found in a kernel oops. Our algorithm achieves 92% accuracy compared to 26% for the traditional approach of using only the oops instruction pointer. We integrated the solution into a tool named OOPSA, which would relieve some burden for the developers with the kernel oops debugging.Lorsqu'une erreur survient dans le noyau Linux, celui-ci émet un rapport d’erreur appelé "kernel oops" contenant le contexte d’exécution de cette erreur. Les kernel oops décrivent des erreurs réelles de Linux, permettent de classer les efforts de débogage par ordre de priorité et de motiver la conception d’outils permettant d'améliorer la fiabilité du code de Linux. Néanmoins, les informations contenues dans un kernel oops n’ont de sens que si elles sont représentatives et qu'elles peuvent être interprétées correctement. Dans cette thèse, nous étudions une collection de kernel oops provenant d'un dépôt maintenu par Red Hat sur une période de huit mois. Nous considérons l’ensemble des caractéristiques de ces données, dans quelle mesure ces données reflètent d’autres informations à propos de Linux et l’interprétation des caractéristiques pouvant être pertinentes pour la fiabilité de Linux. Nous constatons que ces données sont bien corrélées à d’autres informations à propos de Linux, cependant, elles souffrent parfois de problèmes de duplication et de manque d’informations. Nous identifions également quelques pièges potentiels lors de l'étude des fonctionnalités, telles que les causes d'erreurs fréquentes et les causes d'applications défaillant fréquemment. En outre, un kernel oops fournit des informations précieuses et de première main pour un mainteneur du noyau Linux lui permettant d'effectuer le débogage post-mortem car il enregistre l’état du noyau Linux au moment du crash. Cependant, le débogage sur la seule base des informations contenues dans un kernel oops est difficile. Pour aider les développeurs avec le débogage, nous avons conçu une solution afin d'obtenir la ligne fautive à partir d’un kernel oops, i.e., la ligne du code source qui provoque l'erreur. Pour cela, nous proposons un nouvel algorithme basé sur la correspondance de séquences approximative utilisé dans le domaine de bioinformatique. Cet algorithme permet de localiser automatiquement la ligne fautive en se basant sur le code machine à proximité de celle-ci et inclus dans un kernel oops. Notre algorithme atteint 92% de précision comparé à 26 % pour l’approche traditionnelle utilisant le débogueur gdb. Nous avons intégré notre solution dans un outil nommé OOPSA qui peut ainsi alléger le fardeau pour les développeurs lors du débogage de kernel oops

Oops! What about a Million Kernel Oopses?

When a failure occurs in the Linux kernel, the kernel emits an "oops", summarizing the execution context of the failure. Kernel oopses describe real Linux errors, and thus can help prioritize debugging efforts and motivate the design of tools to improve the reliability of Linux code. Nevertheless, the information is only meaningful if it is representative and can be interpreted correctly. In this paper, we study a repository of kernel oopses collected over 8 months by Red Hat. We consider the overall features of the data, the degree to which the data reflects other information about Linux, and the interpretation of features that may be relevant to reliability. We find that the data correlates well with other information about Linux, but that it suffers from duplicate and missing information. We furthermore identify some potential pitfalls in studying features such as the sources of common faults and common failing applications.Lorsqu'une défaillance survient dans le noyau de Linux, le noyau émet un rapport de "oops" qui résume le contexte d'exécution à ce moment. Les "kernel oopses" décrivent des vrais problèmes de Linux. Ils peut aider à fixer des priorités pour les tâches de mise au point et motiver le développement d'outils permettant d'améliorer la fiabilité du code de Linux. Néanmoins, les informations des oops ne sont significatives que si elles sont représentatifs et sont interprétées correctement. Dans cet article, nous étudions les kernel oopses mémorisés pendant huit mois par Red Hat. Nous considérons les caractéristiques générales de ces rapports, la corrélation entre les rapports et d'autres informations éxtérieures, et l'interprétation des caractéristiques liée à la fiabilité de Linux. Notre étude montre principalement (i) que les kernel oopses sont corrélés aux informations extérieures, (ii) les kernel oopses souffrent de problémes de duplication et d'absence de rapports. Par ailleurs, nous avons identifiés des pièges á éviter dans l'étude des sources des fautes usuelles et dans les applications fréquement défaillantes

Oops! What about a Million Kernel Oopses?

When a failure occurs in the Linux kernel, the kernel emits an "oops", summarizing the execution context of the failure. Kernel oopses describe real Linux errors, and thus can help prioritize debugging efforts and motivate the design of tools to improve the reliability of Linux code. Nevertheless, the information is only meaningful if it is representative and can be interpreted correctly. In this paper, we study a repository of kernel oopses collected over 8 months by Red Hat. We consider the overall features of the data, the degree to which the data reflects other information about Linux, and the interpretation of features that may be relevant to reliability. We find that the data correlates well with other information about Linux, but that it suffers from duplicate and missing information. We furthermore identify some potential pitfalls in studying features such as the sources of common faults and common failing applications.Lorsqu'une défaillance survient dans le noyau de Linux, le noyau émet un rapport de "oops" qui résume le contexte d'exécution à ce moment. Les "kernel oopses" décrivent des vrais problèmes de Linux. Ils peut aider à fixer des priorités pour les tâches de mise au point et motiver le développement d'outils permettant d'améliorer la fiabilité du code de Linux. Néanmoins, les informations des oops ne sont significatives que si elles sont représentatifs et sont interprétées correctement. Dans cet article, nous étudions les kernel oopses mémorisés pendant huit mois par Red Hat. Nous considérons les caractéristiques générales de ces rapports, la corrélation entre les rapports et d'autres informations éxtérieures, et l'interprétation des caractéristiques liée à la fiabilité de Linux. Notre étude montre principalement (i) que les kernel oopses sont corrélés aux informations extérieures, (ii) les kernel oopses souffrent de problémes de duplication et d'absence de rapports. Par ailleurs, nous avons identifiés des pièges á éviter dans l'étude des sources des fautes usuelles et dans les applications fréquement défaillantes