Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

st.cs.uni-saarland.de

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#31

Post by khedoros1 »

ericfrederich wrote: post #23

The GDB people have done it again. The new release 4.17 of the GNU debugger [6] brings several new features, languages, and platforms, but for some reason, it no longer integrates properly with my graphical front-end DDD [10]: the arguments specified within DDD are not passed to the debugged program. Something has changed within GDB such that it no longer works for me. Something? Between the 4.16 and 4.17 releases, n…

I couldn't quickly find the 4.17 release, but gdb 4.17.0.4 was released at the end of June 1998. The release notes mentioned Linux kernels in the 2.0-2.1 range.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#32

Post by brainfire »

atonse wrote: post #9

We once had a bug that would cause a failure in our test suite, but very rarely. It was so rare that it would just "go away" and not show up for weeks. So we thought it was odd (maybe bad test data, etc) but moved on. When we decided to look into it when we had some downtime, we found out that it was a date bug that only reared its head on the 31st day of the month, hence only happening every two months. I'm not sure…

Related bug- OpenOffice can't print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...

Previous HN thread: https://news.ycombinator.com/item?id=8171956

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#33

Post by muxxa »

maccard wrote: post #28
azhenley wrote: post #14

Earlier quoted context omitted.

This is awesome. Didn't know about it, thanks! My approach has been to step exponentially. I go back 1 commit, 2 commits, 4 commits... etc. I'll be using bisect from now on though.

Heh, I do a binary search. Find last known good build, go half way between, etc

I wish git bisect could handle the 'find last good build' step by jumping back exponentially through history, then switching to binary search once the last good build is found

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#34

Post by sethrin »

pmarreck wrote: post #13
warpech wrote: post #2

Reminds me of one of the nice features of Git: git bisect. Find the breaking commit in the smallest number of steps. Some random blog post about it: http://webchick.net/node/99

how am I not surprised that this solved a regression that occurred at some point in the past on a Drupal project I worked on a Drupal project... Once.

I believe Joomla is worse in every conceivable way. And then of course there is WordPress, which I sincerely hope is the last major procedurally-written codebase. PHP has come a long way as a language (it can almost be confused for something sensible these days) but lots of issues with large libraries.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#35

Post by T_D_K »

Why does the article say there are 2^N different possible configurations? Shouldn't it be N! ? Maybe I'm missing something, but I don't see how they can rule out so many different orderings of the "configurations", since he started out by saying that the ordering wasn't reliable.

Edited: I figured it out. It's because they essentially do a binary search of the changes to find the issue, I should have read a bit further before commenting. The tables / examples cleared it up pretty quickly.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#36

Post by MaulingMonkey »

adrianratnapala wrote: post #16
devrandomguy wrote: post #12

Earlier quoted context omitted.

Git bisect is awesome. Before I discovered it, I was manually bisecting the codebase, and stubbing out the missing half.

Not to take away from git bisect (or hg bisect, which is no more broken than the rest of mercurial) -- I don't think it is an alternative to the thing you used to do. git bisect is "temporal bisection", i.e. you delete half of a time interval. The manual bisect is kinda-sorta "spatial" in the sense that you delete half a region of code. the two things work by similar principles, and their problem domains overlap -- b…

They're complimentary techniques. One might git bisect down to the commit level, then manually bisect the sub-changes in the commit if it's a large one.

I've done the manual equivalent in perforce as well.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#38

Post by pmarreck »

sethrin wrote: post #34
pmarreck wrote: post #13

Earlier quoted context omitted.

how am I not surprised that this solved a regression that occurred at some point in the past on a Drupal project I worked on a Drupal project... Once.

I believe Joomla is worse in every conceivable way. And then of course there is WordPress, which I sincerely hope is the last major procedurally-written codebase. PHP has come a long way as a language (it can almost be confused for something sensible these days) but lots of issues with large libraries.

That's why I left the Ruby ecosystem and went to Elixir. I noticed that my coding style was getting more and more functional (just naturally... but I was also probably influenced by Rich Hickey's "Are We There Yet?" talk, and by Gary Bernhardt's "Boundaries" talk) and soon realized that functional nirvana was essentially unachievable in Ruby as long as I depended on a vast library of gems all of which were procedural/OO.

Leaped and haven't looked back yet. Great stuff.

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#39

Post by sethrin »

pmarreck wrote: post #38
sethrin wrote: post #34

Earlier quoted context omitted.

I believe Joomla is worse in every conceivable way. And then of course there is WordPress, which I sincerely hope is the last major procedurally-written codebase. PHP has come a long way as a language (it can almost be confused for something sensible these days) but lots of issues with large libraries.

That's why I left the Ruby ecosystem and went to Elixir. I noticed that my coding style was getting more and more functional (just naturally... but I was also probably influenced by Rich Hickey's "Are We There Yet?" talk, and by Gary Bernhardt's "Boundaries" talk) and soon realized that functional nirvana was essentially unachievable in Ruby as long as I depended on a vast library of gems all of which were procedural…

I started in PHP, migrated to Ruby, and now I think I am beginning to be annoyed at Ruby's occasional lack of expressivity. I am probably on a similar course towards FP nirvana. Do you know any place on the left coast that's playing with Elixir or Haskell?

Re: Yesterday, my program worked. Today, it does not. Why? (1999) [pdf]

#40

Post by dsw108 »

Here's an implementation of a modified version of his delta debugging algorithm we did for minimizing file inputs that induce a failure in a compiler or static analysis tool: http://delta.tigris.org/

Also works for other kinds of files of course. Our version is easily seen as a kind of simulated annealing, with the input providing sufficient randomness that we did not need to add any internally.

Fun story: this was my first open source project. I had always wanted to be an open source programmer, but the precipitating cause of me releasing delta was that Microsoft Research asked me to. So back when Microsoft was saying that open source is a "cancer" I became an open source programmer because Microsoft asked me to.

Post reply on HN