The 'rr' project gets a side mention, but if you're into debuggers, it's really worth a look - a very practical "record and replay" debugger that allows you to move around in time in a debug session. http://rr-project.org/
How I Found a 20-Year-Old Linux Kernel Bug
21–30 of 45 posts
Re: How I Found a 20-Year-Old Linux Kernel Bug
#22Linux ~4.7 or so fixed a bug in fadvise, specifically FADV_DONTNEED, that incorrectly rounded page boundaries to the effect of making some calls less effective. Found and fixed by a developer who wondered why his page cache was filling up, even though the backup software he used made use of DONTNEED :) The bug was in from day 1.
The thing I wonder about in instances like this is how many people ran into the problem and thought, "Huh, there must be some quirky rationale here, and it's just an idiosyncrasy I'll have to deal with", or, "Huh, that's definitely wrong... oh well".
I can definitely say that I've been guilty of seeing a subtle but not deal breaking bug in third party open source software and then failing to file a report because there's just so much to do in a day that it's easy to forget. It's on all of us to be good open source citizens.
Re: How I Found a 20-Year-Old Linux Kernel Bug
#23It's always nice to see fixes of problems found with improved testing. It would be nice to see something like Haskells QuickCheck rigorously applied on the majority of the kernel functions/interfaces.
Something like https://github.com/google/syzkaller ?
Wow, they found 458 bugs in the linux kernel: https://github.com/google/syzkaller/blob/master/docs/found_b...
Re: How I Found a 20-Year-Old Linux Kernel Bug
#24given enough eyeballs, all bugs are shallow
Sure, but it's not at all clear eyeballs are the most efficient way to find bugs. They seem remarkably inefficient compared to computers, which have generally shown themselves to be good at monotonous mechanical work that requires good attention to detail and no creativity. In particular it seems to me like this could have been fixed with a better, machine-readable description of the types/structures for each ioctl,…
The quoted soundbite is intended to be pithy, not 100% literal. It's ok if some of the eyeballs are in fact implemented with automated static analysis.
Re: How I Found a 20-Year-Old Linux Kernel Bug
#25Linux ~4.7 or so fixed a bug in fadvise, specifically FADV_DONTNEED, that incorrectly rounded page boundaries to the effect of making some calls less effective. Found and fixed by a developer who wondered why his page cache was filling up, even though the backup software he used made use of DONTNEED :) The bug was in from day 1.
The thing I wonder about in instances like this is how many people ran into the problem and thought, "Huh, there must be some quirky rationale here, and it's just an idiosyncrasy I'll have to deal with", or, "Huh, that's definitely wrong... oh well".
[deleted]
Re: How I Found a 20-Year-Old Linux Kernel Bug
#26Earlier quoted context omitted.
The thing I wonder about in instances like this is how many people ran into the problem and thought, "Huh, there must be some quirky rationale here, and it's just an idiosyncrasy I'll have to deal with", or, "Huh, that's definitely wrong... oh well".
I can definitely say that I've been guilty of seeing a subtle but not deal breaking bug in third party open source software and then failing to file a report because there's just so much to do in a day that it's easy to forget. It's on all of us to be good open source citizens.
I think the counter point of this is being kind when people report bugs that aren't bugs.
If users encounter a weird result, report it, and have someone call them an idiot because they misunderstood a nuance of the system... they're probably not going to take the time to report next time around.
(And I get it, there's that common issue that people consistently misunderstand and you continually get reports about. But each one of those users might also be a user who finds a real bug next time.)
Re: How I Found a 20-Year-Old Linux Kernel Bug
#27given enough eyeballs, all bugs are shallow
This bug was in code which very few applications would ever use, and its manifestation is quite specific, so it's no surprise that it was never discovered. I don't doubt that more of these "benign" bugs exist in other exotic pieces of code in the kernel; in light of this, perhaps the saying should be "given enough bugs, all eyeballs are shallow."
Re: How I Found a 20-Year-Old Linux Kernel Bug
#28Love the modesty implicit in the short post.
Re: How I Found a 20-Year-Old Linux Kernel Bug
#29Title should have been "How i found a bug in some deprecated 802.11g-era API that is disabled by default"
I always wonder why the kernel does not just warn when this API is used or yank it. Any software stuck with this API can barely know about 802.11n and is probably wondering what is 802.11ac or 802.11ax. Only some old or broken device drivers require this API.
Linux distros should just stop enabling this API.
Re: How I Found a 20-Year-Old Linux Kernel Bug
#30Earlier quoted context omitted.
I can definitely say that I've been guilty of seeing a subtle but not deal breaking bug in third party open source software and then failing to file a report because there's just so much to do in a day that it's easy to forget. It's on all of us to be good open source citizens.
I think the counter point of this is being kind when people report bugs that aren't bugs. If users encounter a weird result, report it, and have someone call them an idiot because they misunderstood a nuance of the system... they're probably not going to take the time to report next time around. (And I get it, there's that common issue that people consistently misunderstand and you continually get reports about. But…
I think your parenthetical probably explains the dismissive attitude many upstreams have, but I would argue that if so many people are (consistently) misunderstanding your software then there's probably a UI/UX/education problem that needs fixin'...
(Not saying it's easy, but it's a sign...)