Could this have been foreseen/avoided if the code (written by someone else and being reused by you, if I understand correctly) had been better commented?
You hit the nail right on the head, Unitron. I would have preferred to have had a union of the structure and the pointer, so the size of the whole thing would've been adjusted automatically if the structure's size got stripped down below four bytes. Nevertheless, a simple "/* Structure is overwritten by pointers in obscure_garbage_routine()" would have been inelegant but would've set off alarm bells in my head when I did the prot.
The fact is, though, that latent bugs exist in most systems and that by porting code we implictly accept the code in its entirety - bugs and all. That's why (IMHO) you have to test it to the same level as if it was brand new: source code should be tested and inspected to its core, COTS DLLs should be tested for interface errors, and pieces of hardware should be hammered with invalid signals, messages, and environmental conditions.
assumed... a simple mechanical electrical switch in the lock mechanism
sql*kitten: So did I when I came on board! The fact is that in a widebody aircraft, everything is wired into some kind of computer. For lighting, it's simply because it's cheaper and weighs less to have a primative LAN than to directly wire a switch from your seat, through the floor, up around the interior wall of the plane, and back up to your reading lamp in the ceiling. For everything else, there's usually master controls so the attendants can override anything (cancel all the attendant calls, ring everyone in the toilets to go back to their seats, etc).
smart enough to know how many cubicles are occupied and adjust a single toilet-free indicator in the main passenger section
appropriately?
Actually, the way the plumbing is, there are multiple tanks serving different toilets. The system simply "occupies" those that don't work and the passengers have to hike to find empty ones.
BOUNUS TRIVIA: If a depressurization alarm goes off, the "return to seats" light go off everywhere in the plane except the toilets. Someone who wrote our requirements (FAA?) probaly did a study or something and found that it was safer to sit on the throne than try to stumble back to your seat during a huricanne!
Agreed. I've been to many costume parties (not revels) put on by fellow members where you are not allowed to come in garb. Usually works, but there was a 60's theme party where no one came as hippies and everyone showed as riot police. 'Says a lot about how our minds work alike...
Well, since I aluded to this in the main post, I guess I should come clean on
my "Two Toilet Reset" story.
Before that, though, I need to make some things perfectly clear:
The buggy code never made it onto any aircraft. It was caught
during integration in a laboratory by our customer (the manufacturer
of the aircraft) nearly a year before the first test flight of the system.
Like most everything on any aircraft, the lighting system was
designed to handle other systems (including embedded computers)
acting flakey. Resetting the
lighting computer would not have killed the lights or plunged the cabin
into darkness. It simply would have disabled some of the
automated lighting controls (e.g. dim the lights before the movie, etc.)
for a short period of time.
The bug was entirely my fault and does not reflect on the
quality of the products by my employer or our customer. In fact, the fact
that it was caught speaks highly of the processes put in place by
aircraft manufacturers, the FAA, and aviation regulators throughout
the world.
Whew! Now that that's out of the way, here's the tale (pardon the length)...
The system I was working on controlled the cabin lighting, reading
lights, attendant call lights, and the public address sytem for a popular
passenger aircraft. Basically, all automated functions (except for in
flight entertainment - movies, video games and such) that are used by
anyone in the passenger cabins. One input was a discrete that indicated
when a toilet valve was thrown (flushed). The discrete
would stay set if the waste tanks were filled with, er, waste. Our system
would light the "toilet occupied" light above the door, which we normally
only lit when another discrete indicated the door was locked.
For various reasons, we were upgrading the computers to an embedded 80186,
a workhorse 16 bit processor that my company had a lot of experience with.
As a technical lead, I ported an executive (it would be misleading to
call it an "embedded operating system," but it did the same job) that
we had used on another 80186 based system.
The discrete driver used a linked list to handle queued inputs, chaining
a number of structures together, each about 20 bytes big. I did not need
a lot of the features the driver had, so I pared it
down to a three byte structure. What I didn't know was that the garbage
collection routine did a type casting trick with a four byte pointer
(instead of putting the pointer into the structure itself) which would overwrite the
three byte structures. The net result
was that the chaining was worthless: the driver interrupt routine could
only handle one input each time it ran (at 60Hz).
During our in house testing, we hit the dicretes as fast as we could, but
we never caused the bug to show up. Our customer, however, had a dedicated lab that simulated an entire 400 passenger aircraft.
To allow a single operator to stress test the system, a lot of
the inputs (passenger reading light switches, attendant call switches, etc)
were wired together. One such arrangement was wiring two
"toilet waste tank full" discretes together.
So, shortly after we delivered our first hardware and software to the lab,
the lab guys were checking out the wiring on their test stands. One of them
threw the ganged switch (that is, flushed two toilets).
My driver recieved two inputs in the same 1/60
of a second. It read the first, processed it just fine, then tried to read the
second via a corrupted pointer and... BAM!!... my computer reset.
The lab guys thought it was hillarious. My boss was less amused, I'm afraid.
The moral of the story? I guess that, first, you can never have too
much integration. I hammered on our test rack for hours on end,
but we never had thought to wire multiple discretes together (heck, the
customer's lab guys only did it because it was more convenient than throwing
multiple switches at once). If it had made it into the field, I guarentee
we never would've found the root cause (what are the odds of a
flight attendant standing next to a toilet with a stopwatch?).
The other moral is the one I've heard a million times but didn't take to heart
until this bug bit me: ported code is new code. I didn't understand the
garbage collection in the driver and just took it on faith that because it
had worked on the old project that it would work on this one. You have to
understand (and test) ported code just as much as you would stuff you wrote
yourself.
I wonder if any studio would make Ringworld, without screwing it up?... they'd make the first one, it would be a huge success
CAVEAT: I'm completely uniformed of all matters Hollywood. Take everything I write here with a grain of salt the size of Rhode Island.
With that said... I played the Ringworld video game back in the early 90's. Basically, it was way too long on narrative to work well. It was only then that I realized just how dependent Niven's stuff is on narration and/or his characters' inner dialog. Heck, just seeing the history of the Man-Kzin wars spelled out graphically (as opposed to spread over a few chapters of Niven's prose) made my eyelids sag. I fear any Known Universe film would have to devote so much time info-dumping that it'd be serriously handicapped right out of the gate.
So, you'd one heck of a talented screenwriter to make the adaptation work and then need an incredibly brave studio executive to provide budget for a first rate cast, crew, and effects. That seems theoretically doable, if incredibly unlikely, in Hollywood today.
The big thing that would kill it before it left the boardroom, though, would be the marketing angle. I mean, can you see Speaker to Animals ("seven feet of sentient carnivore") on a Happy Meal? Sure, they could turn him into a giant Ewok (after sedating and/or institutionalizing Niven), but it'd be a lot cheaper to just develop a more suitable property from the ground up.
I do see one way you could do an end run around most of these issues: make it an animated feature. Your effects problems are solved immediately, and my guess (as an extreemely uniformed Hollywood outsider) is that a cast of talented voice actors could be had for less than a cast of big name stars. Also, the cynic in me thinks that having actors you're used to seeing in a more "human" scale might detract from Ringworld's grand scope ("Look at the size of that wall behind Teela!" vs. "Man, that wall behind Julia Roberts is too big to be real"). For that reason, you would not want well known/big budget faces on the screen.
Basically, my point is that the effects budget and cast salary to pull off a live action Ringworld would be so high that it would dwarf the (substantial) cost of doing it as an animated feature.
With that said, though, I don't know if I'd want to see a Ringworld movie. As a fan, I have a hunch that even the most incredible animation out of Pixar (or effects out of ILM) would be second rate to my imagination.
Dho! 'Guess this is why American schooling gets such a bad rap. Not that my High School gave me incorrect information, but that I slipped through quality control able to forget about the Hindus.;)
PS - After writting the above, I noticed another "US-ism." Specifically, the use of "American" for "relating to the United States," as opposed to the many other residents of North and South America. In defense, I'm tempted to point out the use of the term "Norteamericano" in Mexico for refering to us gringos (even though Mexico is in North America), but I'm scared because I leaned that in High School, as well.
So, is this (the use of.US domains) going to be a step towards a more international Internet, even a baby step?
I know that people (esp in the mainstream press) marvel at how global the Internet is, but the fact is that it is inherently biased towards people in the US. Personally, unless I have reason to think otherwise (e.g. oxford.edu, moscowballet.org, airfrance.com, etc) I (incorrectly) tend to assume that a domain is on my side of the pond (or Pacific, or Canadian or Mexican border). It strikes me as unfair that a business running in the UK realistcally has to grab both.co.uk and.com domains to be sure that they reach their (UK) customers while I could simply buy eds-taco-palace.com and everyone knows it's in the States.
On the gripping hand... if we are entering an era of U.S. hedgmony, perhaps this skewed view is appropriate. After all, if the Romans had the Internet, would they have confided themselves to a ".rmn" country code?
PS - Random thought - imagine IP addresses in Rome: ccv.xcv.xxx.ii. But then they'd have had to cross the Atlantic and conquer the Aztecs to get zero and make it work...
The problem here is that LINUX is the poster child in the mainstream/financial world. The appearance of this is (IMHO) a blow to open source in the mainstream, especially on the heels of M$oft releasing XP.
Dho! Forget that last quetion. Just read the posts about Webpoison. I'll probably use it so I can design my own CGI. I also like the idea of using a SPAMcatcher address...
I've implemented a post gate on my site, as described here. Unfortunately, the mail account attached to it is already getting SPAM, so I can't tell if it's working. Does anyone know if the 'bots that SPAMers use these days are sophisticated enough to handle post methods?
The SPAMBOT Beware has a lot of other suggestions, and any page titled SPAMbot Harassment gets my vote. I do wonder how effective these dated (~1999) techniques would be today. Any opinions?
Finally, I was thinking of implementing a SPAMbot CGI trap that sleeps, say, five seconds before posting a page of bogus addresses (and domains) and a link to another page that's simply a soft link to itself. Does this sound like it ought to work? After all, if I like recursion, shouldn't a SPAMbot?;)
Related question: multicast file transfer
on
A Better FTP?
·
· Score: 1
Some of the other solutions mentioned here might already handle this, but I am ignorant enough of them to ask the question anyway...
On our latest project, we have a large number of embedded targets running Windows CE on a TCP/IP (cable modem) connection to a file server running Windows NT. We have requirements to be able to download identical images to all the targets for software upgrades within a certain period.
The problem is that TCP does not support a multicast to multiple targets - you essentially wind up retransmit the same data over and over again. With a certain number of targets, the numbers come out taking longer to do a system upgrade than using an older legacy serial link that supported broadcast.
So, here's my question: Does anyone know of a multicast file transfer protocol (not simply serial FTP) that is suitable for this application, preferably something open source?
OK, the article indicated these critters grew to these lengths in 50 to 60 years.
Does anyone know how long a modern croc takes to reach full growth (say, 12 feet)? For that matter, what about "hyper-giant" animals in general, such as those giant sharks in the paleozoic (or whatever period it was)?
PS - Maybe I should've titled this "does size matter?"
Isolation is a nice goal, but makes for all kinds of headaches.
Case in point: I work with embedded targets and our local PC network run NT 4.0 (no jokes, please...). The RTOS we use requires a TCP/IP connection for debug and file transfer. To get your code into the box you can either (a) go down two flights of stairs and use a flash burner to load your code or (b) hook up your target to your PC. You can guess what we use.
Our IT department gives us zero support as developers. By this I mean that they will not allocate dedicated development workstations, routers, bridges, firewalls, PCs with extra network cards, even mechanical switchboxes - anything that will help us isolate our targets from the rest of the net. We get the exact same level of support that finance or human resources does. So, our developers are stuck throwing together kludges that are basically accidents waiting to happen just so they can talk to their targets and get their company mandated EMAILs.
If our IT department were to implement a literal double standard, creating one policy that supports non technical users (go anywhere you want, but with restricted privilleges), and another for developers (play all you want behind your personal firewall), we developers could make all the mistakes we need to and not crash each other or the payroll mainframe.
Such a policy would also reduce problems on our LAN, as a lot of our developers never mess with TCP/IP details - they're working on embedded GUIs or audio drivers. Once IT set up their isolating firewall, they'd probably never touch it again. Those that do much around... IT wouldn't have to (and shouldn't have to) clean up their messes.
Sure, it probably won't happen in this lifetime, but I can dream, can't I?
Slashdot Mirror
My sympathies. :)
jsfetzik, I hate to ask, but was your comiler C/C++? If so, did it support the volatile type or did the optimizer wipe it out anyway?
You hit the nail right on the head, Unitron. I would have preferred to have had a union of the structure and the pointer, so the size of the whole thing would've been adjusted automatically if the structure's size got stripped down below four bytes. Nevertheless, a simple "/* Structure is overwritten by pointers in obscure_garbage_routine()" would have been inelegant but would've set off alarm bells in my head when I did the prot.
The fact is, though, that latent bugs exist in most systems and that by porting code we implictly accept the code in its entirety - bugs and all. That's why (IMHO) you have to test it to the same level as if it was brand new: source code should be tested and inspected to its core, COTS DLLs should be tested for interface errors, and pieces of hardware should be hammered with invalid signals, messages, and environmental conditions.
sql*kitten: So did I when I came on board! The fact is that in a widebody aircraft, everything is wired into some kind of computer. For lighting, it's simply because it's cheaper and weighs less to have a primative LAN than to directly wire a switch from your seat, through the floor, up around the interior wall of the plane, and back up to your reading lamp in the ceiling. For everything else, there's usually master controls so the attendants can override anything (cancel all the attendant calls, ring everyone in the toilets to go back to their seats, etc).
smart enough to know how many cubicles are occupied and adjust a single toilet-free indicator in the main passenger section appropriately?
Actually, the way the plumbing is, there are multiple tanks serving different toilets. The system simply "occupies" those that don't work and the passengers have to hike to find empty ones.
BOUNUS TRIVIA: If a depressurization alarm goes off, the "return to seats" light go off everywhere in the plane except the toilets. Someone who wrote our requirements (FAA?) probaly did a study or something and found that it was safer to sit on the throne than try to stumble back to your seat during a huricanne!
Agreed. I've been to many costume parties (not revels) put on by fellow members where you are not allowed to come in garb. Usually works, but there was a 60's theme party where no one came as hippies and everyone showed as riot police. 'Says a lot about how our minds work alike...
Whew! Now that that's out of the way, here's the tale (pardon the length)...
The system I was working on controlled the cabin lighting, reading lights, attendant call lights, and the public address sytem for a popular passenger aircraft. Basically, all automated functions (except for in flight entertainment - movies, video games and such) that are used by anyone in the passenger cabins. One input was a discrete that indicated when a toilet valve was thrown (flushed). The discrete would stay set if the waste tanks were filled with, er, waste. Our system would light the "toilet occupied" light above the door, which we normally only lit when another discrete indicated the door was locked.
For various reasons, we were upgrading the computers to an embedded 80186, a workhorse 16 bit processor that my company had a lot of experience with. As a technical lead, I ported an executive (it would be misleading to call it an "embedded operating system," but it did the same job) that we had used on another 80186 based system.
The discrete driver used a linked list to handle queued inputs, chaining a number of structures together, each about 20 bytes big. I did not need a lot of the features the driver had, so I pared it down to a three byte structure. What I didn't know was that the garbage collection routine did a type casting trick with a four byte pointer (instead of putting the pointer into the structure itself) which would overwrite the three byte structures. The net result was that the chaining was worthless: the driver interrupt routine could only handle one input each time it ran (at 60Hz).
During our in house testing, we hit the dicretes as fast as we could, but we never caused the bug to show up. Our customer, however, had a dedicated lab that simulated an entire 400 passenger aircraft. To allow a single operator to stress test the system, a lot of the inputs (passenger reading light switches, attendant call switches, etc) were wired together. One such arrangement was wiring two "toilet waste tank full" discretes together.
So, shortly after we delivered our first hardware and software to the lab, the lab guys were checking out the wiring on their test stands. One of them threw the ganged switch (that is, flushed two toilets). My driver recieved two inputs in the same 1/60 of a second. It read the first, processed it just fine, then tried to read the second via a corrupted pointer and... BAM!!... my computer reset.
The lab guys thought it was hillarious. My boss was less amused, I'm afraid.
The moral of the story? I guess that, first, you can never have too much integration. I hammered on our test rack for hours on end, but we never had thought to wire multiple discretes together (heck, the customer's lab guys only did it because it was more convenient than throwing multiple switches at once). If it had made it into the field, I guarentee we never would've found the root cause (what are the odds of a flight attendant standing next to a toilet with a stopwatch?).
The other moral is the one I've heard a million times but didn't take to heart until this bug bit me: ported code is new code. I didn't understand the garbage collection in the driver and just took it on faith that because it had worked on the old project that it would work on this one. You have to understand (and test) ported code just as much as you would stuff you wrote yourself.
CAVEAT: I'm completely uniformed of all matters Hollywood. Take everything I write here with a grain of salt the size of Rhode Island.
With that said... I played the Ringworld video game back in the early 90's. Basically, it was way too long on narrative to work well. It was only then that I realized just how dependent Niven's stuff is on narration and/or his characters' inner dialog. Heck, just seeing the history of the Man-Kzin wars spelled out graphically (as opposed to spread over a few chapters of Niven's prose) made my eyelids sag. I fear any Known Universe film would have to devote so much time info-dumping that it'd be serriously handicapped right out of the gate.
So, you'd one heck of a talented screenwriter to make the adaptation work and then need an incredibly brave studio executive to provide budget for a first rate cast, crew, and effects. That seems theoretically doable, if incredibly unlikely, in Hollywood today.
The big thing that would kill it before it left the boardroom, though, would be the marketing angle. I mean, can you see Speaker to Animals ("seven feet of sentient carnivore") on a Happy Meal? Sure, they could turn him into a giant Ewok (after sedating and/or institutionalizing Niven), but it'd be a lot cheaper to just develop a more suitable property from the ground up.
I do see one way you could do an end run around most of these issues: make it an animated feature. Your effects problems are solved immediately, and my guess (as an extreemely uniformed Hollywood outsider) is that a cast of talented voice actors could be had for less than a cast of big name stars. Also, the cynic in me thinks that having actors you're used to seeing in a more "human" scale might detract from Ringworld's grand scope ("Look at the size of that wall behind Teela!" vs. "Man, that wall behind Julia Roberts is too big to be real"). For that reason, you would not want well known/big budget faces on the screen.
Basically, my point is that the effects budget and cast salary to pull off a live action Ringworld would be so high that it would dwarf the (substantial) cost of doing it as an animated feature.
With that said, though, I don't know if I'd want to see a Ringworld movie. As a fan, I have a hunch that even the most incredible animation out of Pixar (or effects out of ILM) would be second rate to my imagination.
Again, take it all with a grain of salt...
PS - After writting the above, I noticed another "US-ism." Specifically, the use of "American" for "relating to the United States," as opposed to the many other residents of North and South America. In defense, I'm tempted to point out the use of the term "Norteamericano" in Mexico for refering to us gringos (even though Mexico is in North America), but I'm scared because I leaned that in High School, as well.
I know that people (esp in the mainstream press) marvel at how global the Internet is, but the fact is that it is inherently biased towards people in the US. Personally, unless I have reason to think otherwise (e.g. oxford.edu, moscowballet.org, airfrance.com, etc) I (incorrectly) tend to assume that a domain is on my side of the pond (or Pacific, or Canadian or Mexican border). It strikes me as unfair that a business running in the UK realistcally has to grab both .co.uk and .com domains to be sure that they reach their (UK) customers while I could simply buy eds-taco-palace.com and everyone knows it's in the States.
On the gripping hand... if we are entering an era of U.S. hedgmony, perhaps this skewed view is appropriate. After all, if the Romans had the Internet, would they have confided themselves to a ".rmn" country code?
PS - Random thought - imagine IP addresses in Rome: ccv.xcv.xxx.ii. But then they'd have had to cross the Atlantic and conquer the Aztecs to get zero and make it work...
The problem here is that LINUX is the poster child in the mainstream/financial world. The appearance of this is (IMHO) a blow to open source in the mainstream, especially on the heels of M$oft releasing XP.
Dho! Forget that last quetion. Just read the posts about Webpoison. I'll probably use it so I can design my own CGI. I also like the idea of using a SPAMcatcher address...
Check out the page entitled "SPAMBOT Harassment" on the SPAMBOT Beware page. It's a little dated (~1999) but looks reasonable to me.
On our latest project, we have a large number of embedded targets running Windows CE on a TCP/IP (cable modem) connection to a file server running Windows NT. We have requirements to be able to download identical images to all the targets for software upgrades within a certain period.
The problem is that TCP does not support a multicast to multiple targets - you essentially wind up retransmit the same data over and over again. With a certain number of targets, the numbers come out taking longer to do a system upgrade than using an older legacy serial link that supported broadcast.
So, here's my question: Does anyone know of a multicast file transfer protocol (not simply serial FTP) that is suitable for this application, preferably something open source?
Thanks
Does anyone know how long a modern croc takes to reach full growth (say, 12 feet)? For that matter, what about "hyper-giant" animals in general, such as those giant sharks in the paleozoic (or whatever period it was)?
PS - Maybe I should've titled this "does size matter?"
Isolation is a nice goal, but makes for all kinds of headaches. Case in point: I work with embedded targets and our local PC network run NT 4.0 (no jokes, please...). The RTOS we use requires a TCP/IP connection for debug and file transfer. To get your code into the box you can either (a) go down two flights of stairs and use a flash burner to load your code or (b) hook up your target to your PC. You can guess what we use. Our IT department gives us zero support as developers. By this I mean that they will not allocate dedicated development workstations, routers, bridges, firewalls, PCs with extra network cards, even mechanical switchboxes - anything that will help us isolate our targets from the rest of the net. We get the exact same level of support that finance or human resources does. So, our developers are stuck throwing together kludges that are basically accidents waiting to happen just so they can talk to their targets and get their company mandated EMAILs. If our IT department were to implement a literal double standard, creating one policy that supports non technical users (go anywhere you want, but with restricted privilleges), and another for developers (play all you want behind your personal firewall), we developers could make all the mistakes we need to and not crash each other or the payroll mainframe. Such a policy would also reduce problems on our LAN, as a lot of our developers never mess with TCP/IP details - they're working on embedded GUIs or audio drivers. Once IT set up their isolating firewall, they'd probably never touch it again. Those that do much around... IT wouldn't have to (and shouldn't have to) clean up their messes. Sure, it probably won't happen in this lifetime, but I can dream, can't I?