Re:Heisenbugs...
on
Debugging
·
· Score: 2, Insightful
In my experience, Heisenbugs are often the result of race conditions between concurrent threads.
Yeah, but thread problems are so slippery, I don't even think of them as Heisenbugs. I think of them as Neutrinobugs.
A stack-related Heisenbug (or really any kind of Heisenbug, for that matter) will always occur in the same place, given the same conditions. Always the same location, always the same stack trace. But when you stick in a print statement, the bug moves, or - worse - it goes away altogether. That'll make you pull your hair out the first couple of times it happens to you, but after a while you learn to spot them pretty quickly.
Race conditions between threads, however, are maddening in their irregularity. They rarely happen in the same place at the same time. (If they do, you're lucky.) They can be random in when they choose to pop up. One time you might run five minutes before you see a crash. Next time, you might run hours before the program falls over and dies. And when you do get a crash, it's never in the same place, and often it's not even "near" the bad code. Two threads write to the same data structure at the same time because it wasn't locked correctly - and the program can continue running WAAAAY past the bad access. I've seen grown men brought to their knees, sobbing like little children, over threading problems. Race conditions keep suicide hotlines in business.
And people wonder why I'm compulsive about putting locks around my data.
Re:Wouldn't you take the car to a mechanic?
on
Debugging
·
· Score: 1
Too bad you omitted the story - it's a good one. This is a Car Talk story, isn't it? The car would start when the guy bought chocolate ice cream, but it wouldn't start if he bought vanilla. Turns out the two are in different parts of the store, one much further away. If he had to walk further for the vanilla, the car wouldn't start because it had sat long enough to develop vapor lock.
Re:Heisenbugs...
on
Debugging
·
· Score: 4, Insightful
Heisenbugs are almost always caused by buffer overflows.
In my experience, Heisenbugs are almost always caused by stack problems. That's why they go away when you put print statements in the code - because you're causing the usage of the stack to change.
Buffer overflows (to arrays on the stack) are one good way to munge the stack. Returning the address of an input parameter or automatic variable is another way, because these are declared on the stack and cease to exist when the enclosing block exits. Anybody else using such an address is writing into the stack in an undefined manner, and chaos can result!
What, the same "The Time Machine" that was written by HG Wells?
Wells and Clarke are the same person. Clarke went back in time to write under a pseudonym.
Re:Another *really* nice thing about the golden ra
on
The Golden Ratio
·
· Score: 1
Another slick thing is that it is the limit of ratios of successive terms in a Fibonacci (or similar) sequence.
In fact, this can be demonstrated.
At any point in the Fibbonaci sequence, the values are..., m, n, m+n,...
Now, if you assume that the ratio of terms converges (proof left as exercise for reader), then, as the number of terms approaches infinity, the ratios of adjacent pairs of terms approaches equality:
n/m = (m+n)/n
or
n/m = m/n + 1
substitute x = n/m:
x = 1/x + 1
AHA! We're back to the equation representing the number that is 1.0 larger than its reciprocal! Solve the quadratic to get
x = (1 + sqrt(5))/2
The golden ratio.
Something I learned from Martin Gardner...
on
The Golden Ratio
·
· Score: 5, Informative
Something I like about the golden ratio is that it is the number that is exactly 1.0 greater than its reciprocal. This makes it easy to remember the exact value: just solve
x = 1 + 1/x
You'll get a quadratic with the solutions (1 +/- sqrt(5))/2, or 1.618... and -0.618...
I might note that in any given murder case the significant other is at the top of the list of people to investigate. However it is increadably unprofessional for a reporter to make the same speculation.
Well, if the reporter presented the speculation as fact, then that would be incredibly unprofessional (Jayson Blair notwithstanding). In this case, though, it's clear that the reporter is speculating - in particular when he leads off the statement with the phrase "There is no proof".
I have purchased replacement batteries and a replacement keyboard for my aging Dell Inspiron 3700 from laptopsforless.com. I wasn't terribly impressed with the lifetime of the batteries - they wore out in just over a year, whereas the original Dells had lasted 18 months before dying (I can be hard on batteries). The keyboard was a refurb, but has performed adequately.
You could always buy a sacrificial laptop on eBay and use it for parts. If it's old enough, it won't cost you too much.
The K-1000 is great for beginners because it simplifies the task down to its essential controls - focus, shutter speed, and aperture. No fancy modes, auto-this, auto-that. By learning to use a fully manual camera, you'll improve your technique on an automatic camera, because then you'll know when it's better to turn off some of that automatic stuff.
I bought my K-1000 back in '86, and it's still one of my favorite cameras. My only (minor) complaint is that I'd rather have a split-prism focusing screen; I find them easier to use than the microprism screen in the K-1000. Too bad the focusing screens can't easily be changed out.
Find yourself a gently used K-1000 and have a great time.
Why can't they just shout "Let 'er rip!!" and crank the thing wide open?
If it were that easy, I'm sure they'd do just that. But a cluster of over 1000 machines is a complex contraption and I'm willing to bet that tuning it to get the last drop of performance out of it is not a simple task. It's probably a theorize, measure, tweak loop getting small increments of performance gain on each iteration. It's probably going to take them some time before they get it fully tweaked out.
Since the new software is a derivative work of something already licensed by the GPL, the new software must remain under the GPL.
Unless all the copyright holders of the original work agree to relicense it under non-GPL terms, which is their right.
Regardless of whether or not the additional changes are a work-made-for-hire, both parties should agree who owns the changes, how they are to be licensed, and this agreement should be written down and signed by both parties.
As I understand the GPL, if the company in question wishes to pay any individual to work on code...code which they will be using "in-house," they CAN insist that those changes not be made public.
OK, I'm going to go out on a limb here, even though I only scored 77% on the GPL Quiz (and the only way I'll ever score Seven of Nine).
Yeah, you're right - even though the changes are covered under the GPL as a derivative work, if the company doesn't redistribute the binary then they don't have to give the source to anybody.
But I'm assuming the author probably wants to redstribute the changes - in which case he'd better be sure the company allows him to retain ownership of the changes or to redistribute. The author and the company that hires him need to agree on who owns the changes and how/if to distribute them.
I was in this situation a few years ago, when a company wanted some mods done to a camera-control library I had written and publish on sourceforge. Because they were a well-funded company, I charged them an hourly rate. However, because they were funding an open-source project, and because their changes were fairly small, I was willing to give them a break. I charged $50 an hour - less than half what I would have charged on a project for proprietary code.
I'd suggest you take into consideration who the company is, what they want to do with the code, and what their financial situation is. For example, I wouldn't charge a big, well-established company the same I would charge a non-profit.
Also make sure the company understands who owns the code you produce. Many companies don't understand how open-source licenses work, and might assume that, because they've paid for it, your code belongs to them and doesn't continue to fall under the restrictions of your chosen license. Understand your license fully and make sure the company that's paying understands it too. (Just to avoid disputes in the future, you might want to capture that understanding in your contract, or in a side agreement.)
...SCO announced today that they would be suing Valve for copyright infringement, because the Half Life 2 source code contained "over a million lines" if its unix source code.
Activation isn't handled by the kernel -- it's part of the Win32 subsystem and is entirely user-mode.
So what? The problem with activation is how it identifies the machine. I install XP on partition A. I install linux on partition B. Then on partition B, I use Xen to make a second installation of XP, or I try to run the version install on partition A. What matters to me as a user is whether the copy of XP running under Xen needs a second license. If the activation algorithm thinks that both copies of XP are running on the same machine (which they are), then I can activate both copies of XP under the same license. If not, I have to buy a second copy - even though I'm running it on the same machine.
In being so quick to chastise the guy for not reading the article, you missed the point. If anything at all needs to be ported, it means that an OS like XP can't be installed on Xen out of the box. It means that a port of the XP kernel has to be completed, and that MS has to authorize the ported kernel to be distributed. For lots of folks, this is not good enough... even assuming that MS ever would allow the ported kernel to be distributed (and then we have to worry about activation issues too). So, while Xen is great for allowing linux users to run multiple distros at max performance at the same time, it doesn't much help someone who wants to run XP, and might never help them. Those folks still have to resort to VMWare or Bochs.
I remember LBX being buggy. In fact, the reason I didn't use it more was it had a very bad habit of spontaneously dropping its connection to the X server. Since what I needed was to run XEmacs, I just ran it in TTY mode over a telnet session. It was almost as good, a bit faster, and dependable.
Slashdot Mirror
In my experience, Heisenbugs are often the result of race conditions between concurrent threads.
Yeah, but thread problems are so slippery, I don't even think of them as Heisenbugs. I think of them as Neutrinobugs.
A stack-related Heisenbug (or really any kind of Heisenbug, for that matter) will always occur in the same place, given the same conditions. Always the same location, always the same stack trace. But when you stick in a print statement, the bug moves, or - worse - it goes away altogether. That'll make you pull your hair out the first couple of times it happens to you, but after a while you learn to spot them pretty quickly.
Race conditions between threads, however, are maddening in their irregularity. They rarely happen in the same place at the same time. (If they do, you're lucky.) They can be random in when they choose to pop up. One time you might run five minutes before you see a crash. Next time, you might run hours before the program falls over and dies. And when you do get a crash, it's never in the same place, and often it's not even "near" the bad code. Two threads write to the same data structure at the same time because it wasn't locked correctly - and the program can continue running WAAAAY past the bad access. I've seen grown men brought to their knees, sobbing like little children, over threading problems. Race conditions keep suicide hotlines in business.
And people wonder why I'm compulsive about putting locks around my data.
Too bad you omitted the story - it's a good one. This is a Car Talk story, isn't it? The car would start when the guy bought chocolate ice cream, but it wouldn't start if he bought vanilla. Turns out the two are in different parts of the store, one much further away. If he had to walk further for the vanilla, the car wouldn't start because it had sat long enough to develop vapor lock.
Heisenbugs are almost always caused by buffer overflows.
In my experience, Heisenbugs are almost always caused by stack problems. That's why they go away when you put print statements in the code - because you're causing the usage of the stack to change.
Buffer overflows (to arrays on the stack) are one good way to munge the stack. Returning the address of an input parameter or automatic variable is another way, because these are declared on the stack and cease to exist when the enclosing block exits. Anybody else using such an address is writing into the stack in an undefined manner, and chaos can result!
What, the same "The Time Machine" that was written by HG Wells?
Wells and Clarke are the same person. Clarke went back in time to write under a pseudonym.
Another slick thing is that it is the limit of ratios of successive terms in a Fibonacci (or similar) sequence.
..., m, n, m+n, ...
In fact, this can be demonstrated.
At any point in the Fibbonaci sequence, the values are
Now, if you assume that the ratio of terms converges (proof left as exercise for reader), then, as the number of terms approaches infinity, the ratios of adjacent pairs of terms approaches equality:
n/m = (m+n)/n
or
n/m = m/n + 1
substitute x = n/m:
x = 1/x + 1
AHA! We're back to the equation representing the number that is 1.0 larger than its reciprocal! Solve the quadratic to get
x = (1 + sqrt(5))/2
The golden ratio.
Something I like about the golden ratio is that it is the number that is exactly 1.0 greater than its reciprocal. This makes it easy to remember the exact value: just solve
x = 1 + 1/x
You'll get a quadratic with the solutions (1 +/- sqrt(5))/2, or 1.618... and -0.618...
I might note that in any given murder case the significant other is at the top of the list of people to investigate. However it is increadably unprofessional for a reporter to make the same speculation.
Well, if the reporter presented the speculation as fact, then that would be incredibly unprofessional (Jayson Blair notwithstanding). In this case, though, it's clear that the reporter is speculating - in particular when he leads off the statement with the phrase "There is no proof".
Red Hat is irrelevant... Mandrake is irrelevant... RESISTANCE IS FUTILE!
I have purchased replacement batteries and a replacement keyboard for my aging Dell Inspiron 3700 from laptopsforless.com. I wasn't terribly impressed with the lifetime of the batteries - they wore out in just over a year, whereas the original Dells had lasted 18 months before dying (I can be hard on batteries). The keyboard was a refurb, but has performed adequately.
You could always buy a sacrificial laptop on eBay and use it for parts. If it's old enough, it won't cost you too much.
The K-1000 is great for beginners because it simplifies the task down to its essential controls - focus, shutter speed, and aperture. No fancy modes, auto-this, auto-that. By learning to use a fully manual camera, you'll improve your technique on an automatic camera, because then you'll know when it's better to turn off some of that automatic stuff.
I bought my K-1000 back in '86, and it's still one of my favorite cameras. My only (minor) complaint is that I'd rather have a split-prism focusing screen; I find them easier to use than the microprism screen in the K-1000. Too bad the focusing screens can't easily be changed out.
Find yourself a gently used K-1000 and have a great time.
--Jim
Why can't they just shout "Let 'er rip!!" and crank the thing wide open?
If it were that easy, I'm sure they'd do just that. But a cluster of over 1000 machines is a complex contraption and I'm willing to bet that tuning it to get the last drop of performance out of it is not a simple task. It's probably a theorize, measure, tweak loop getting small increments of performance gain on each iteration. It's probably going to take them some time before they get it fully tweaked out.
What would be your choice for middle school classrooms with minimal sys admin?
Fisher-Price. Anything with Barney or Pooh-Bear on it.
IBM PCs most certainly did use ctrl-S and ctrl-q to stop and start scrolling in DOS mode. And you know what? Windows STILL DOES!
You can also find this functionality on almost any unix-like system; it's part of any decent VT100 emulator.
The Pilot Razor Point is cheap enough to be bought in quantity, and has a hard plastic nib a little like a fountain pen.
The Razor Point is nice, but I prefer the Razor Point II. Sharper point, thinner line, nice dark ink.
Why haven't they agreed on a standard format for DVDs yet?
What do you mean? They've agreed on many, many standards. So many standards we can each have one! Just take your pick...
I guess Saddam got tired of trying to pick up the spare on those 7-10 splits.
Since the new software is a derivative work of something already licensed by the GPL, the new software must remain under the GPL.
Unless all the copyright holders of the original work agree to relicense it under non-GPL terms, which is their right.
Regardless of whether or not the additional changes are a work-made-for-hire, both parties should agree who owns the changes, how they are to be licensed, and this agreement should be written down and signed by both parties.
As I understand the GPL, if the company in question wishes to pay any individual to work on code...code which they will be using "in-house," they CAN insist that those changes not be made public.
OK, I'm going to go out on a limb here, even though I only scored 77% on the GPL Quiz (and the only way I'll ever score Seven of Nine).
Yeah, you're right - even though the changes are covered under the GPL as a derivative work, if the company doesn't redistribute the binary then they don't have to give the source to anybody.
But I'm assuming the author probably wants to redstribute the changes - in which case he'd better be sure the company allows him to retain ownership of the changes or to redistribute. The author and the company that hires him need to agree on who owns the changes and how/if to distribute them.
I was in this situation a few years ago, when a company wanted some mods done to a camera-control library I had written and publish on sourceforge. Because they were a well-funded company, I charged them an hourly rate. However, because they were funding an open-source project, and because their changes were fairly small, I was willing to give them a break. I charged $50 an hour - less than half what I would have charged on a project for proprietary code.
I'd suggest you take into consideration who the company is, what they want to do with the code, and what their financial situation is. For example, I wouldn't charge a big, well-established company the same I would charge a non-profit.
Also make sure the company understands who owns the code you produce. Many companies don't understand how open-source licenses work, and might assume that, because they've paid for it, your code belongs to them and doesn't continue to fall under the restrictions of your chosen license. Understand your license fully and make sure the company that's paying understands it too. (Just to avoid disputes in the future, you might want to capture that understanding in your contract, or in a side agreement.)
...SCO announced today that they would be suing Valve for copyright infringement, because the Half Life 2 source code contained "over a million lines" if its unix source code.
Activation isn't handled by the kernel -- it's part of the Win32 subsystem and is entirely user-mode.
So what? The problem with activation is how it identifies the machine. I install XP on partition A. I install linux on partition B. Then on partition B, I use Xen to make a second installation of XP, or I try to run the version install on partition A. What matters to me as a user is whether the copy of XP running under Xen needs a second license. If the activation algorithm thinks that both copies of XP are running on the same machine (which they are), then I can activate both copies of XP under the same license. If not, I have to buy a second copy - even though I'm running it on the same machine.
it's OK to use a cut up beer can to fix excess play in the wheels of their expensive motorcyles.
Handlebars. Pirsig used a piece of aluminum from a beer can to shim out some loose handlebars. Or at least he suggested it...
...and that paper title tells us how to pronounce Xen, at least if you're familiar with the Robert Pirsig title.
In being so quick to chastise the guy for not reading the article, you missed the point. If anything at all needs to be ported, it means that an OS like XP can't be installed on Xen out of the box. It means that a port of the XP kernel has to be completed, and that MS has to authorize the ported kernel to be distributed. For lots of folks, this is not good enough... even assuming that MS ever would allow the ported kernel to be distributed (and then we have to worry about activation issues too). So, while Xen is great for allowing linux users to run multiple distros at max performance at the same time, it doesn't much help someone who wants to run XP, and might never help them. Those folks still have to resort to VMWare or Bochs.
Pfff...
I remember LBX being buggy. In fact, the reason I didn't use it more was it had a very bad habit of spontaneously dropping its connection to the X server. Since what I needed was to run XEmacs, I just ran it in TTY mode over a telnet session. It was almost as good, a bit faster, and dependable.
I'd love to see NX succeed where LBX failed.