Eric S. Raymond Identifies A Common Programming Trap: 'Shtoopid' Problems (ibiblio.org) 189
"There is a kind of programming trap I occasionally fall into that is so damn irritating that it needs a name," writes Eric S. Raymond, in a new blog post:
The task is easy to specify and apparently easy to write tests for. The code can be instrumented so that you can see exactly what is going on during every run. You think you have a complete grasp on the theory. It's the kind of thing you think you're normally good at, and ought to be able to polish off in 20 LOC and 45 minutes.
And yet, success eludes you for an insanely long time. Edge cases spring up out of nowhere to mug you. Every fix you try drags you further off into the weeds. You stare at dumps from the instrumentation until you're dizzy and numb, and no enlightenment occurs. Even as you are bashing your head against a wall of incomprehension, consciousness grows that when you find the solution, it will be damningly simple and you will feel utterly moronic, like you should have gotten there days ago.
Welcome to programmer hell. This is your shtoopid problem.... If you ever find yourself staring at your instrumentation results and thinking "It...can't...possibly...be...doing...that", welcome to shtoopidland. Here's your mallet, have fun pounding your own head. (Cue cartoon sound effects.)
Raymond's latest experience in shtoopidland came while working on a Python-translating tool, and left him analyzing why there's some programming conundrums that repel solutions. "You're not defeated by what you don't know so much as by what you think you do know," he concludes. So how do you escape?
"[I]nstrument everything. I mean EVERYTHING, especially the places where you think you are sure what is going on. Your assumptions are your enemy; printf-equivalents are your friend. If you track every state change in the your code down to a sufficient level of detail, you will eventually have that forehead-slapping moment of why didn't-I-see-this-sooner that is the terminal characteristic of a shtoopid problem."
Share your own stories in the comments. Are there any programmers on Slashdot who've experienced their own shtoopid problems?
And yet, success eludes you for an insanely long time. Edge cases spring up out of nowhere to mug you. Every fix you try drags you further off into the weeds. You stare at dumps from the instrumentation until you're dizzy and numb, and no enlightenment occurs. Even as you are bashing your head against a wall of incomprehension, consciousness grows that when you find the solution, it will be damningly simple and you will feel utterly moronic, like you should have gotten there days ago.
Welcome to programmer hell. This is your shtoopid problem.... If you ever find yourself staring at your instrumentation results and thinking "It...can't...possibly...be...doing...that", welcome to shtoopidland. Here's your mallet, have fun pounding your own head. (Cue cartoon sound effects.)
Raymond's latest experience in shtoopidland came while working on a Python-translating tool, and left him analyzing why there's some programming conundrums that repel solutions. "You're not defeated by what you don't know so much as by what you think you do know," he concludes. So how do you escape?
"[I]nstrument everything. I mean EVERYTHING, especially the places where you think you are sure what is going on. Your assumptions are your enemy; printf-equivalents are your friend. If you track every state change in the your code down to a sufficient level of detail, you will eventually have that forehead-slapping moment of why didn't-I-see-this-sooner that is the terminal characteristic of a shtoopid problem."
Share your own stories in the comments. Are there any programmers on Slashdot who've experienced their own shtoopid problems?
try this in whitespace... (Score:1)
how on earth would you instrument *this*?? https://en.wikipedia.org/wiki/... [wikipedia.org]
Not always... (Score:5, Interesting)
More times than not, the solution is actually really difficult - you just underestimated the problem. Then you go to github and find a library that shows you how it should be done, and you can't believe it takes so much code to do something that seemed so straightforward.
Re:Not always... (Score:5, Informative)
... can't believe it takes so much code to do something that seemed so straightforward.
While that happens too, it is on the other end of the spectrum of what Eric is describing.
Re:Not always... (Score:4, Interesting)
This bug was extremely elusive for me because the code looks fine and watermark in our data is almost never between 00:00:00 and 01:00:00 and that was when the bug sometimes causes missing data in our target tables.
Re: Not always... (Score:4, Interesting)
Sometimes it's a very slight difference between environments that causes problems. We rolled out some code to production that had been fully tested in Dev and Test environments. Things started to break due to SQL errors. Ran the SQL directly on the production database server but it ran fine. Somehow the SQL was getting different results running through the production server than it was on the production database server directly.
After some investigation the only difference between the production server and other environments was the server used a slightly older database driver. It was a minor version difference. How this caused errors was that in the older db driver all math operations had to be explicit data casts despite what documentation said but the newer driver followed the database documentation. So Integer A / Integer B should be implicitly cast as Integer according to the documentation. However the older driver would cast that as Float for some unknown reason and that would cause errors.
But this would only happen using the db driver on Production. Testing the SQL directly on Production DB wouldn't have found it. Testing the code and SQL on Dev and Test servers wouldn't have found the bug. The patch notes for the db driver didn't mention the change.
Re: (Score:2)
Re: Not always... (Score:2)
Re: Not always... (Score:2)
Re: Not always... (Score:2)
There are gads of ways they are different; however, as coders we neither have the ability, permission, or control to make sure that they are identitical in every single way. In some cases these are unavoidable. The production environment is a 6 cpu server located in CA for example. The Dev and Test servers are 2 CPU servers located locally. But here's the thing: as coders we made sure that we developed on the as close to Production as we could. We didn't think that a db driver was enough to cause a differen
Re: (Score:2)
Nice example of how to do something completely wrong.
Re:Not always... (Score:5, Insightful)
Agreed. But I don't really think Eric's "solution" is that helpful. Heres the last two "shtoopid" problems I had (in a CFD model evolution app):
1) My program (which a piped child process, which in turn had its own children) was randomly locking up when one of the subprocess's children died. Now, normally that's an eminently solveable problem... except for the fact that it was locking up in a different place each time. I was stuck digging deeper and deeper into pipe magic with no luck. I even went to strace python, but that just added more confusion, as strace was dying at random times, and sometimes not even printing out full lines!
The problem? The output of my program was running through "tee". I was only seeing the last section of the buffer to be printed out :P The real problem was that the subprocess had simply stopped printing data and so the pipe read was hanging; it was instantly obvious when "tee" wasn't used.
2) My program would sometimes go into a "subprocess keeps dying" mode. This started out of the blue with no changes to my code. Again, I kept instrumenting more and more, with no luck.
The problem? I had started, in another window, a shell script that ran on a loop to generate visualization data at regular intervals whenever the process was running. When the visualization data would appear in the middle of a run, it would sometimes interfere with the raw data, due to the way the data processing was set up. But since that visualization data wasn't present when the run started, it took time for the problem to show up, and then would just occur out of the blue.
The short of this is... if you follow Eric's "instrument everything" solution to "shtoopid" problems, you'll sometimes just dig yourself further into a hole. The problem is that you have a base assumption that's wrong. IMHO, the best solution is to bring a third party in and explain everything about what you're doing and where it's going wrong. Not only can their different perspective add insight, but the very act of having to explain and reproduce everything from scratch (and answer their questions) can help you as well.
Re: (Score:2)
I go the exact opposite direction of him!
Just stop looking at the instrumentation as if you're researching a problem or doing R&D. You're not doing R&D when you have a trivial mistake you can't find, you're just debugging.
Stop looking at the tools. Look at the code. If you find yourself saying, "It...can't...possibly...be...doing...that" just whack yourself over the head with the cartoon hammer right there, because telling yourself that is why you're having trouble finding it. You have to instead be
Re: (Score:2)
Yes, I agree that some problems are more complicated than they seem, especially if you need to synchronise with some other state, or a poorly documented piece of software.
State is the key problem, the article is right about that. If I find these problems, I try to eliminate states as much as possible. Sometimes a different programming approach help. Reconstructing a value rather than saving it reduces complexity. But sometimes you need the state, and then you may want to look at state machine theory, which
Re: (Score:2)
I got woken up very early once because somebody knew the 100 year exception for leap years but apparently not the 400 year exception to the exception.
Re: (Score:2)
Unfortunately, had to do my own.
Date of easter, sunrise/sunset times. No good C++ library providing these.
Get a better debugger (Score:1)
Re:Get a better debugger (Score:5, Insightful)
Or with experience you realise that stepping debuggers are great for some problems and printfs are great for other problems.
Re: (Score:2)
One problem I encountered with an early C++ compiler was that a chain of function calls which had a function in the middle that had a return result of "int" would actually return the result of the last function call it itself had made,even if no return result was supplied. While this was the actual intention, it was spooky that no value was returned. Any attempts to add new code would just make this fail.
Re: (Score:2)
Re: (Score:2)
Which is why the newer compilers give warnings in that case.
Re: (Score:2)
I knew people who relied on non-standard or indeterminate compiler behavior like that. Then they'd move to a new machine or upgrade the compiler and complain that it wasn't working right or that it was now giving warnings about code that they thought was perfectly fine.
Nothing said (Score:2, Insightful)
Assert is your friend (Score:5, Insightful)
Been there, got several wardrobes full of T shirts.
If unit testing and staring at code for more than a few minutes doesn't solve this kind of problem, then the assertion hammer comes out. Assert everything, especially the things that are so obvious that they don't need an assertion. The bugs just have fewer and fewer places to hide and eventually surrender.
Re: (Score:2, Interesting)
These are always humorous comment threads.
Everyone has some experience. Everyone has plenty of advice. Lots of absolutes (like the parent's) come out.
Point number one, always, is to check our assumptions. We assume we know how to code. We assume others know how to code. We assume libraries work as documented. We assume compilers are logical. We assume we are.
Men assume women are logical. Fun ensues.
Kids assume parents are good examples. And waste decades of their lives.
Physics drifts away from the
assert()'s for every assumption (Score:5, Interesting)
Over my 30 year career, I cannot believe how many 'C' programmers I've come across who are unfamiliar with the assert() macro. This macro is essential for trapping all invalid assumptions! Usually it's as simple as:
if ( ! functionWhichCanFail(a,b,c) ) assert(0);
Run your program from the debugger, and it will stop when the assert(0) is encountered, giving you full and convenient access to everything needed to hunt down the issue.
Re: (Score:1)
as a user, nobody wants the program to abruptly shut down when something goes wrong, often losing their work. this is why a lot of modern languages de-emphasize or completely lack things like assert and exceptions
Re:assert()'s for every assumption (Score:5, Informative)
Re: (Score:2)
And when the dev forgets to turn it off for that one little module, hilarity reigns when the feed gets random debug messages in it.
Re: (Score:2)
Several places I worked had a policy of leaving all asserts in place for production release. I think the rationale is that half the bugs are found by customers, which is another problem in itself.
Re:assert()'s for every assumption (Score:5, Informative)
You got the right way to say it: "Assert all of your assumptions."
Code rots when it gets modified in ways that don't respect the implicit assumptions made in the past. Have you ever said to yourself, "this function is only called from two places and I know those two places validate the parameters"? When you then write the function without checking parameters, you've made an implicit assumption that makes all the sense in the world at that moment. But someone else (or you in three months) will forget or won't know the assumption, and call that function from somewhere else, with unchecked parameters.
Either document your implicit assumptions (making them explicit), or (better) assert them. The way to get good at asserting implicit assumptions is first to learn how to recognize when you're making an implicit assumption! That takes skill and practice, but if you don't do it, asserts don't help you.
And I leave the asserts in the final builds, too. In decades of professional C programming, I've never had a case where the asserts imposed a measurable performance penalty.
To the people who say "use NDEBUG to disable your asserts for production, because customers hate interruptions": no, don't do that. A violation of an implicit assumption is ALWAYS a bug, and it's always better for it to bite your behind sooner rather than later. The assert tells you exactly what you did wrong. I've had this conversation dozens of times:
[Angry customer]: Your software crashed!
[Me]: pop open the syslog and search for the word "assert."
[Angry customer]: It says "line XXX in file YYY"!
[Me]: you'll have the fix in two hours.
Interestingly, there is a handful of classes of bugs that are impervious to asserting your assumptions. The worst of these, in my experience, is the accidentally shadowed variable. But using assert in a disciplined way is incredibly useful.
Re: (Score:2)
I have had to remove asserts where the code was too big to fit on the chip anymore. I found a few asserts, verified that they could not possibly happen, and removed them.
For most stuff I've worked in in the last couple of decades, the assert causes a mysterious reboot and coredump.
Re: (Score:2)
One thing I've done a lot is to rewrite the assert macro so that it leaves a syslog trace. Another thing you can do (if you're lucky enough to get a coredump on failure) is to arrange for a distinctive signal (like SIGABRT) to hit your program. That stands out nicely in the coredump.
Re: (Score:2)
[Angry customer]: The software I was using crashed with an assert code!
[St. Peter]: Yes, we'll have to talk to the car manufacturer about that.
Most of the software I work on can emit smoke, mangle parts, or lose data if it were to abort. There's a place for assert(), but it's not always an option.
Re: (Score:2)
They can sometimes be annoying. Ie, "assert(0)" for me often generates a code dump where I can't see the actual value of the original culprit variables anymore, since the compiler thinks the variables in don't need to be saved and the assert code itself scribbles all over the registers.
Another problem with asserts is that they need to be about REAL errors. I've seen many cases where an assert has happened at a customer and when investigating you see that the assert itself is the error. Often the devs jus
Re: (Score:2)
As with every tool and technique, there are right ways and wrong ways to use it.
To one of your points: sometimes it's not easy to figure out the best or most consistent way to handle a problem, when you expect it to happen never or almost never. A perfect example is when you can't create a realistic test case! In that case, I'd rather write an assert and get a deterministic and easily-fixable failure in the field, than write complicated error handling and recovery that I can't easily test.
One time I nearly
Re: (Score:3)
A "professional" programmer bragging how much he is ignorant.
*facepalm*
Hint: If you aren't using all the (language's debugging) tools available then you aren't as smart, or professional, as you think you are. A "real" professional would go "Oh cool, this defensive programming -- an implementation of Fail Fast -- will help in tracking down bugs! Nice!"
C programmers who don't use assert() are either ignorant, stupid, writing toy programs, or some combination. Period.
Re: (Score:3)
Not the way I'd do it. An assert is always to be considered an orthogonal instrumentation of code, not code itself. The code must ALWAYS work according to intent, with or without the assert. The point of the assert is to detect when the intent isn't correct or has changed over time due to violated assumptions.
Write it this way:
auto ok = FunctionWhichShouldntEverFail (a,b,c);
assert (ok);
In short: always have the assert as its own statement (easily removed or commented out); and only assert values, not functi
printf() may not work for multithreaded problems (Score:4, Interesting)
A few years ago I had an issue in a multi-threaded program where using printf()'s caused the problem to go away. In order to track the problem down, I ended up writing messages to a buffer in RAM, and dumping the buffer to stdout after the problem occurred.
Re: (Score:2)
Re: (Score:2)
I would assume that printf is thread safe on at least some operating systems, printing the whole message and blocking other calls. That would force thread synchronization with the mutex present but hidden. Especially on Windows, where they do a lot to protect users against bad code, without much outside input in those decisions.
Re: (Score:2)
guarantees nothing about when (or in what order) the values of i and j are read and copied into printf's stack frame (which happens before printf is even called just as every other functions' arguments).
Re:printf() may not work for multithreaded problem (Score:5, Interesting)
Fun story time related by a colleague. A pretty common piece of software (hint: there's probably one running within a few hundred yards of you) had an elusive bug. But as the parent noted, printf caused the problem to go away, and it was suspected because it caused synchronization on stdout. Unlike the parent, the developers didn't have time to actually implement a buffered-log solution to figure this out, so they the obviously-logical thing -- they replaced all the printf calls with barrier() [kernel.org] and shipped it. It's still running like this today.
Another good one, I worked with someone who would log everything all the time by fprintfing to a high-numbered pipe. When I asked him, he gave a few advantages that still ring partially true (depends on context): first, he said, I can get the log from any running instance without even stopping by d-tracing the system call. But most critically, he said, all the formatting happens in userland and only after the syscall does the kernel actually realize that there's nothing on the other end of the pipe and drop the write. That means, he reasoned, that the release/debug versions would always have very close behavior and would avoid the class of 'bugs that don't reproduce in debug build'. As with the other story, to this day, there's a slew of machines out there, formatting and writing log messages to a pipe that's never open.
Weeping Angels (Score:3)
I like to think of those kinds of bugs as Weeping Angels. They only move when you're not looking at them.
I have about a dozen years experience in MS Embedded CE. There is typically a Release build, and a Debug build. Release will macro out all the debug statements, which changes the execution timing. Enough so to where the bug that is biting you is often seen only in Release. Switch to Debug to chase it, and it goes away.
I had a similar experience recently with a PIC32 project. The devboard they s
Re: (Score:3)
A few years ago I had an issue in a multi-threaded program where using printf()'s caused the problem to go away. In order to track the problem down, I ended up writing messages to a buffer in RAM, and dumping the buffer to stdout after the problem occurred.
Similar story, except that the processor would reboot, clearing all the variables I stored leaving no opportunity to grab all the diagnostics.
I examined the map, determined what the last address was, added an interrupt handler on the clock that logged the stack pointer ~250/sec (only needed to log the pointer if it was smaller than the existing one) to determine how much margin I had and used that little space between maximum stack and variables to write my diagnostics to.
Once I had determined the smalles
Re: (Score:2)
printf makes calls to malloc/alloc and free to do allocation and deallocation for string construction. There were some libraries that provided the printf functionality using a static pool of memory and string concatenation.
So familiar! (Score:3)
Re: (Score:2)
"But fairly satisfying when you ultimately find the bug."
It is not the kind of problem Raymond is talking about, then.
He is talking about the kind of problem you *know* the solution should be obvious to you from second one and yet, it hides a whole lot of time in which you know, every single second, the problem is laughing at you. When, Bam! you finally find the answer, you know you were right all the time: the solution was obvious, it has been laughing at you at plain sight, and you only feel damn stupid.
Re: (Score:2)
Rubber Duck Debugging (Score:2, Informative)
I learned long ago to recognize the feeling that comes when I know I'm missing something obvious. When I do that, I grab a coworker, and explain the issue to them. Just explaining it to someone is frequently enough, but sometimes they spot something glaringly obvious that I've missing.
I spent an hour once trying to find an issue where the difference was between I5 and l5. Yeah, depending on your font and display that may be an easy problem, or a hard one. One of those is a capital i, the other a lowercase L
Re: (Score:2)
Yep. I think 90% of these problems are caused by
1. Incorrect assumptions about how something that looks simple works. e.g. in Python using sort() (sorts and returns a success flag) instead of sorted (sorts and returns sorted object). I once spent several days tracking down what turned out to be an equation with an ambiguous denominator. The spec author intended (A+B)/(C+D).But elegantly typeset without the parentheses in the spec. The programmer read it as A+ B/C + D
2. Missing punctuation
3. Punctuat
Re: (Score:2)
Re: (Score:2)
Errrm, ... Isn't that simply called 'programming'? (Score:2)
I know this type of thing, is my dayjob. Given, I'm currently doing total LAMP stack web development on setups degraded beyond imagination and a lot of my work involves coming up with crazy hacks and gluecode that gradually inches it's way towards a solution. In order to achieve I do exactly what he describes. It's basically what loosely typed web development is all about. But as far as I can tell, this type of problem is a regular thing in development and results in having to bend our abstraction of realit
Re: (Score:1)
Yes this is just programming. And Eric Raymond's attempt to sound relevant and profound by pontificating and giving names to things which don't really need naming.
Off by one...... (Score:3)
I feel ya brother.. the off by one still gets me 30 years later.
https://en.wikipedia.org/wiki/... [wikipedia.org]
I wish we could have an agreement that lists, arrays, elements, and anything put into a list, table, query, associative array, start with an index value of either 0 or 1.
I don't care just pick one, and don't use two different standards in the same environment.
Re: (Score:3)
Don't forget the old Fortran programmer who moved to C/C++ and insists that all of his arrays start at 1, like God intended, and added some helper functions and macros to do this. Pity the developer who inherited that code and had to maintain it.
Offensive (Score:5, Funny)
Re: (Score:2)
I call myself stupid all the time, this lessens the blow of other people calling me stupid.
Re: (Score:2)
I always say that my all code should be idiot-proofed because I'm one of the idiots. But I do generally write good code.
Sometimes you need to debug optimized code. (Score:2, Informative)
So you have a failed assertion. What happened? Fire up the debugger, breakpoint on abort. Breakpoint gets triggered, you get a backtrace. Can't imagine how you got there.
Days of debugging later...
The abort function is marked as "noreturn". Consequently instead of calling abort, the compiler saves a few bytes/cycles by jumping to a preexisting abort call, never mind the state of the stack frame. Of course, this single recycled abort call in the whole module is where all backtracks end up. Hooray.
Now o
we can do better, but are doing worse (Score:3)
We have solutions to reduce this sort of problem (at least once you get past the learning curve), but the top programming languages tend to implement very few of them. Reasoning about state is difficult, particularly when that state can be altered in unexpected ways. It is difficult to be confident that your code does what you think it does when you don't have a computer-checked method of specifying your intentions separate from what your code does.
There are no magic solutions here, at the least you will end up needing to spend more time writing in a specification language and that requires learning how it works. I would say that a gentle introduction to something like this is Elm [elm-lang.org] which has an aim of stripping down typed functional programming into something that doesn't really need a C.S. degree. Here is a video [youtube.com] which helps to explain what a better type system can do for your code. If you want to see something a bit more mind-bending check out Idris [idris-lang.org] which has a much more powerful specification language which can prevent things like off-by-one errors or unbounded recursion in many cases. Moving off the scale of usability a bit, there is ATS [ats-lang.org] which is a difficult language, but its specification language is able to make pointer arithmetic safe and doesn't bind you to immutable data structures. Hell, even Rust [rust-lang.org] is full of good ideas that help to avoid these issues. And if fault-tolerant distributed systems are your thing, you need to check out Erlang [erlang.org] (or its sibling Elixir [elixir-lang.org]) as there are so many great ideas that have been around for decades yet don't get nearly enough exposure.
This doesn't prevent us all from occasionally falling into this trap, but the themes of the languages listed is to find ways to encourage (or force) you to get the little things right the first time with computer-verified specification and to isolate the search space where problems are likely to occur.
Re: (Score:2, Funny)
Ah yes. The age-old solution to programming problems: Invent another language to throw at it.
Re: (Score:3)
Time (Score:2)
BASHisms (Score:2)
--Try passing BASH commands over SSH to something that Requires Quotes to work right. There's a reason my hair is short.
I really hate this damned PC (Score:2)
I wish that they would sell it.
It never does quite what I want,
but only what I tell it.
Why I was very cautious about time estimate (Score:1)
Back in the day, I'd be given a programming task, and my boss would, naturally, want me to estimate how long it would take. Sometimes it looked like something I could do in maybe a day or two, but I always worried about that elusive bug that might pop up, where I'd get 95% of the coding done in that day or two, but then spend a week tracking down that one knotty problem.
S is for spurious (Score:1)
Eric S. Raymond
Just curious: is there another Eric Raymond with a different middle name that the open source community runs the risk of confusing with this Raymond? If not, why the (therefor apparently labored) inclusion of "S"?
-- not criticizing, just genuinely curious
postfix (Score:2)
setgrey vs setgray
'nuff said
Cold your mind and work in a reasonable order. (Score:1)
Recently I spent "weeks" going behind a configuration problem with a RAID1 in an embedded system I am working with. One of the disks go out of the RAID in a casual way ...
Then, I check the disks and they are OK, I search about my Linux version and some person indicated that "maybe" was because of the particular kernel version, so I improved the kernel. But the new kernel was not OK with my distribution, so I have to change it ... but the new distribution uses different versions of some key libraries forci
Or even worse, the bug vanishes when looked for (Score:2)
I can't remember the details now. (In particular, I cannot remember the date or who drove me home) But I can recall these kinds of bugs where you put in the "print" statement after every line, and figure, NOW it will be revealed... ...and the bug goes away. And I gradually removed print statements and brought the code back to not-inspected, and the bug stays gone.
Your REAL nightmare would be to have it come back at that point, it would start to feel like the X-files. (It's close to that in Ellen Ullma
Under Siege 2: Dark Territory (Score:2)
"Assumption is the mother of all fuck up's!"
WTF? RMS is only now figuring this out??? (Score:1)
Sure, printf is your friend but I have been telling people that for decades now. Nobody ever listened to me when they decided to blame their own naivety on the language or the development suite, or me personally, instead.
Context for ESR's comment: Python-to-Go translator (Score:2)
Home page: http://www.catb.org/esr/pytogo... [catb.org]
This is not too surprising given his recent work on reposurgeon, his previous statements that Python is simply not performant enough for converting the gcc repository from Subversion to git, and his exploration of Rust vs Go as systems programming languages.
!= instead of == or vice versa (Score:3)
Re: (Score:2)
Chasing the SIGBUS (Score:2)
And don't get me started on code which assumes a null pointer is an empty string
Had one of these last week (Score:2)
Had one of these last week. I'd upgraded Groovy (used as a scripting engine) from 2.3 to 2.5 (and 2.4 which also exhibited the problem). Suddenly scripts that extended a custom base script couldn't instantiate the base class due to a missing constructor. The initial script was instantiating, and if I removed extending the base class it was able to execute.
Of course, it was actually working in my IDE.
After multiple days of logging, experimenting, configuring my IDE to (partially) replicate the problem, chasi
Instrumentation is nice, but ... (Score:2)
Shtoopid problems might be programmer hell. Shtoopid problems on a small target that is hard to instrument is the laparascopic version of programmer hell.
forgot a part (Score:2)
so working on this all day, and while driving home, or laying in bed or whatever... the solution pops in your head! you now know what is wrong.
make haste to your desk, implement the thought of solution, which then... comes very close but still isn't perfect.
repeat.
Save your files (Score:2)
A classmate of mine spent 45min trying to debug a crash. Eventually he added some printfs here and there but they didn't trigger. So he added more and more. Still nothing. Then he tried to understand why a "shtoopid" printf didn't work... Eventually he figured out that he never actually saved the file in those 45min, that he had kept running the same binary over and over.
Re:He really is old, isn't he? (Score:5, Insightful)
...he doesn't simply use a debugger to step through the problematic code?
That misses the entire point. In the class of problem he is describing, everything looks fine at the debugging level (regardless of how you are debugging). Or better yet: your debugging tools show that something is wrong, yet how the program gets into that state is elusive. You have traced the program execution in excruciating detail, and everything looks great until the very next line of code morphs your perfect execution state into a problematic one for reasons that appear to be impossible. Eventually, you figure out how it's possible, write a small amount of code that you should have written earlier in the process, and fix the problem.
You then realize the obviousness of the solution, and feel like an idiot for having spent hours, days, weeks, or months figuring it out.
Re: He really is old, isn't he? (Score:2)
While I won't say Eric's name is not suitable, I feel this should be called an "Akerue problem". As to the why, I leave it as an exercise to the reader (and I hope Eric gets to read this).
Re: (Score:3)
I didn't have a debugger, since the stupid chip gets wonky when turning it on. So compile, load the code, look at the oscilloscope, scratch my head, and repeat. I worry I was doing something stupid like it wasn't really loading my new code but had the old code, but that checked out too. Ask for some help over skype, but get nowhere.
Stop and stare at it, the change was supposed to be over and done in 5 to 10 minutes and it's been a few hours. Then I see it, I forgot a "~". I wasn't clearing that bit, I
Re:He really is old, isn't he? (Score:5, Interesting)
Ever tried debugging deep-level OS kernel code?
To be honest, debuggers also introduce just as many differences - I have crafted code (nothing special, fancy or playing tricks) that, when debugged, works entirely differently to non-debugged. Debugging inserts all kinds of stuff into the code that modifies the pointers of all kinds of data by vast amounts, and can made it "pass" whatever it is you wanted to do.
Also, if you program against many architectures, an architecture-specific bug might be something that you don't have the tools for, despite debugging the code on all your normal platforms. Yes, a debugger is the ultimate solution, but mostly you might just not have that stuff available and it could be days or weeks before you can get it going to the point that you can effectively debug code that you've been working on for 20 years and know inside out.
Plus many problems are not debuggable - maybe your users are having the issue but you're not, and you can't reproduce, but dozens of your users can, and yet they have almost identical environments to you - the only way to debug that is to set up a full programming, debugging and source environment on their machine - which may be something you don't want to do - or give them an instrumented version of the executable, which may not reproduce the problem.
I know for a fact that I have programs that work on Linux, Windows, even HTML5 (via emscripten), that also can work on Mac. But for sure I wouldn't be buying a Mac to diagnose problems on that platform until it was absolutely necessary. And I wouldn't be giving my code to users for them to diagnose it.
But through in a bunch of printf's and a log and - no matter the architecture or tools available - you can get down to a function, a line, a set of parameters enough to debug before you even need to think "How the fuck am I'm going to go about getting debug info out of that person/system/architecture?"
I know I have a C macro that I prefix all functions with. In "normal" mode, it just expands to a function definition. In "debug" mode, it expands to the function, and a bunch of debugging lines for when it enters/leaves each function and the parameters given to it. This means one switch change and the program runs basically identically to how it runs without debugging, churns out a huge log file, doesn't modify any structures, pointers, etc. and which I can skim the bottom of after a crash report to know where and why it crashed, on any architecture, with a compiled binary, without including the full -g debugging shit that basically gives away your source code (or a version of it).
Re: (Score:2, Insightful)
We called these "Heisenbugs" - attempting to study the bug (via debugger/variable dumps, etc.) causes it to vanish from sight.
Re: (Score:2)
Or the bug only happens in optimized code but goes away when compiling for debugging. Which means you end up debugging optimized code so that the debugger is uncertain about a variable's value. You end up cross referencing it with an assembler listing.
The fun ones are alignment errors. Which never happen on x86 code so those who only know Windows or Linux on a PC have never encountered these. Stick in a variable to store state for debugging and suddenly things are aligned again. This sometimes leads to
Re: (Score:2)
> Ever tried debugging deep-level OS kernel code?
At least I have. I'm remembering various times, long ago for me, when bugs or limitations in gcc caused difficulty for me applying kernel patches. I sympathize with expanding the reporting to make the critical information visible.
Re: (Score:2)
Hardware is replete with things that evade normal state-based analysis. The spectre bugs show that. Anytime you have a shared resource, you must diagnose the myriad ways of which it could be take advantage. In security, we might view many of these as covert channels. Timing channels are typically the hardest to analyze.
Re: (Score:2)
A kernel debugging itself is tricky, and leads some into a trap when they don't realize that somethings won't debug that way. Using a separate JTAG or other external debugging helps a lot, but sometimes that screws things up too.
What I hate is when there's a bug that depends upon timing so that using a debugger causes it to not happen. But tell the debugger to just run until the bug but then you can't step backwards. If you single step through it, the other tasks aren't running so the bug doesn't appear.
Re: (Score:2)
Instrument everything? Printf is your friend? The guy is talking about something of a few dozen lines of code, and he doesn't simply use a debugger to step through the problematic code? WTF LOL
You're a moron; many problems don't show up under the debugger.
Re: (Score:1)
Some gun guy that apparently also program computers. Or tries to at least.
Re: That's when I usually find bugs in other code (Score:1)
I feel the same way! When my code doesn't work, it's somebody else's fault. :-)
Prevention: if (2 == $a) (Score:2)
I've started preventing that by habitually putting the variable on the right side. If I accidentally use = instead of == I'll get a syntax error.
Re: (Score:2)
Where I work, that's a coding standard, and will get a hard fail in a code review if the variable is on the left side. Of course it's not bulletproof, like if you're comparing two variables, but it helps. Other standards, like requiring braces for even single-line if/thens help as well, at the occasional expense of readability.
Which language? An expression in C++, C#, Java (Score:2)
Which "most C-syntax languages" do you have in mind?
In C++, C#, Java, Perl, and most languages I can think of, assignment is an expression, which means it returns a value.
The sole exception I can think of is that in Rust there IS NO assignment for many kinds of values. In Rust what looks like an assignment:
A = B;
May actually destroy B, making it no longer accessible. The value is moved from B to A, not copied. There can be only one instance of most value types, there cannot be two variables with the value.
Easy prevention: if (10 == variable) (Score:3)
I've started preventing that by habitually putting the variable on the right side. If I accidentally use = instead of == I'll get a syntax error. It makes that bug impossible by just changing an arbitrary habit.
if ( 10 == variable )
Re: (Score:2)
That's the known workaround and highlights another problem that impacts our profession in full: our inability to stand on the shoulders of giants. With each generation, so it seems, we invent a whole lot of new things at the expense of forgetting a lot of things we already knew: two steps forward, one step (and sometimes even two, three or a whole mile) backwards.
Re: (Score:2)
I've started preventing that by habitually putting the variable on the right side. If I accidentally use = instead of == I'll get a syntax error. It makes that bug impossible by just changing an arbitrary habit.
if ( 10 == variable )
I used to do that until compilers started issuing warnings for assignments in conditional expressions; now I simply use the extra braces so that the compiler *KNOWS* that that construct was intended.
Re: (Score:3)
(2) Because they don't distinguish between waste (a) and time consuming functionality (b)
If you are looking for profilers to analyze your code for inefficiencies, then you have a different definition of profiler than I believe most high lever users do. Profilers are there to make a representation of where time/cycles are spent in code. It is up to the author to analyze and act upon such information. And profiling is extremely useful provided you understand the code and infrastructure. You are correct in one way though, it useless for optimization provided you don't know the very basics of p