Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Static code analysis allows you to identify and eliminate many defects at an early stage. Moreover, it's possible to detect dormant errors that don't show themselves when they appear. They can cause many problems in the future and it requires many hours of debugging to detect them. Let's look at an example of such a dormant error.
To show the advantage of regular use of the PVS-Studio static analyzer, we regularly check the Blender project. My colleague wrote more about this idea here.
There is an open project, COVID-19 CovidSim Model, written in C++. There is also a PVS-Studio static code analyzer that detects errors very well. One day they met. Let's embrace the fragility of mathematical modeling algorithms and why you need to make every effort to enhance code quality.
This little story begins with an ordinary search on GitHub. While looking through the search results, I accidentally came across the COVID-19 CovidSim Model project. Without thinking twice, I decided to check it out using the PVS-Studio analyzer.
This summer, Google experts using the ClusterFuzz and OSS-Fuzz tools, discovered a dangerous bug in the Libarchive library, which is responsible for working with archives and compressed files. Libarchive is included by default with Debian, Ubuntu, Gentoo, Arch Linux, FreeBSD, and NetBSD, and the vulnerability allows an attacker to execute arbitrary code on a vulnerable machine. It is reported that Windows and macOS, which also include the library, are not vulnerable.
The bug received the identifier CVE-2019-18408 and allows the attacker to execute arbitrary code in the system using a specially created archive file. The problem can be exploited through a malicious file obtained from cybercriminals through local applications that use various Libarchive components in their work.
Have you ever started an open-source project, dived right into the code, discovered new API features that you loved, fiddled around with the build process, and then take a little break and never come back to it?
If that sounds familiar, this article is for you.
When users experience memory usage issues with any software, including MySQL, their first response is to think that it’s a symptom of a memory leak. As this story will show, this is not always the case.
This story is about a bug.
A software bug is an error or fault in a computer program making it behave in unexpected ways. Bugs can be present at any stage during SDLC (software development lifecycle), or at the design, development, or user-acceptance testing phase. Whether you are testing a web portal for general bugs or for browser-compatibility issues, proper understanding and elimination are necessary.
Bugs can never be eliminated completely. No software can turn out to be 100 percent bug-free. But the testing team can adopt certain practices so that the elimination of bugs from software becomes easy. A good management system ensures that most bugs are found and fixed well before it enters production. If the testers and developers work efficiently, the time period from a bug’s discovery to its abolition can be minimized.
Apple is once again in the news for something they’re certainly not happy about: Another coding bug has been found in the MacOS operating system, this time allowing hackers to change the data of a computer’s most privileged code.
As this piece from Wired explains, the BuggyCow trick (named after the loophole hackers found in the OS’s copy-on-write or CoW protection) “takes advantage of the fact that when a program mounts a new file system on a hard drive – basically loading a whole collection of files rather than altering just one – the memory manager isn't warned. So a hacker can unmount a file system, remount it with new data, and in doing so silently replace the information that some sensitive, highly privileged code is using.”
Since the pre-1.0 betas of CockroachDB, we've been using Jepsen to test the correctness of the database in the presence of failures. We have re-run these tests every night as a part of our nightly test suite. Last fall, these tests found their first post-release bug. This blog post is a more digestible walkthrough of that discovery (many of the links here point to specific comments in that issue's thread to highlight the most important moments).
Running Jepsen tests in an automated fashion has been somewhat challenging. The tests run in a complex environment with network dependencies, spawn multiple cloud VMs, and have many potential points of failure, so they turn out to be rather flaky. If you search our issue tracker for Jepsen failures you'll see a lot of issues, but before the bug we're discussing here, they were all benign — failures of our automation setup, not an inconsistency or bug in CockroachDB itself. By now, though, we've worked out the kinks and have the tests running reliably.
If you’re one of the 35 percent of US adults who use Instagram, you may have awoken Wednesday morning to a bit of a shock: Follower counts across the platform had dropped overnight, with some of the more prolific users losing millions. While many at first speculated that this dramatic reduction was due to yet another round of bot purges, Instagram soon confirmed that a bug was the real culprit.
While this story may at first seem trivial – is it really such a huge deal that Selena Gomez’s depleted follower numbers led to Ariana Grande being crowned the new Instagram pop queen? – it does bring a much more important issue back to the forefront, one posed just last September by cybersecurity expert Raj Goel:
In the digital world, application performance degradation and downtime are not rare occurrences. The impact such incidents have on end-user experience varies. The application may become slow and frustrating to use, or it could crash and impede user transactions. The severity of the issue and the MTTR (Mean Time to Resolve) directly affect end-user experience.
When the titans of information technology encounter performance challenges, the repercussions impact almost every single online application. Such outages are widely reported followed by a slew of write-ups analyzing the issue — what caused it, what fixed it, and what could prevent it. Performance analysts are on the lookout for such big outages, but we often overlook blips in performance. Blips or “micro-outages” are mostly intermittent performance issues that often go unnoticed.
This is the story of a Java debugging journey that started with a question I couldn't answer about Java stack traces. As a long-time Java programmer, I am approached for help by developers who encounter unusual problems in the language. Diving in and getting acquainted with all the dark corners of Java is something I really enjoy, mainly because I emerge with a better understanding of the language, and also because it equips our team with better tools to solve the everyday problems ... as well as the unusual ones.
Our trip takes us through a deeper look at Java lambdas and method references and ends up with a quick foray into the JVM code. We'll use a couple of debugging tools and techniques to figure it all out and learn a little about implementation details and diagnostic JVM options. It's a good example of how, with the source in hand, you can demystify a general phenomenon, such as missing frames.
One of our vehicles needed some recall work to be completed, so Nicole and I made the drop-off the night before the appointment and left the keys in the specially designed drop-box near the service entrance of the dealership.
The following afternoon, Nicole and I arrived back to the dealership. She went inside to get the receipt for the work and I went over to look at the vehicle parked nearby. When I was about halfway there I heard her say, "The keys are in it."