You had one job... Just two lines of code, and now the customer's Inventory Master File has bitten the biscuit How's August working out for you? Why not take a moment out of your private staycation for another tale of cockuppery from the depths of The Register's Who, Me? vault. Today's catastrophic coding comes from a reader we will call "Ed", for that is most definitely not his name, and takes us to Canada in the late 1970s. Ed …
This is going back 30+ years when 1MB was a large machine.
Someone added a comment to some code, compiled it successfully, and submitted it to be integrated. This compile failed with a syntax error. Because it "broke the build" there was an investigation.
The team leader spoke to the junior programmer and stressed the need to compile before integrating. "I did compile it" said the trog*. Team leader said "ok we'll compile it again and show it fails" "oh it works - hey Charlie... here's an interesting problem..." and so on up the chain"
It turns out that when the original program was compiled, the source would fit in memory. When the comment was added, it was too large for memory, and so used "the spill file". This had a bug where it missed a byte when reading from the spill file - and put a garbage byte in the line.
* trog - troglodyte: in pre-historic times, someone who lived in a cave.
"Back in the day, that was quite common"
In this day, it still is
"It works for me" is not a valid reason to ever close a fault (and a good reason to fire support staff who use this one)
The correct response is "I can't replicate your fault, please demonstrate what you're doing so we can observe the issue" - and then close it 14 days after they fail to respond.
off-by-one errors:
When Scottish independence was being even more hotly debated than it is now, I wanted to find out how many Scottish members there were in the House of Lords*.
I went to the Government web site, asked for a list of peers, and was rewarded with the response:
"Found, 781 of 780"
*The House of Lords is an anachronistic legislative chamber peculiar to the (currently) United Kingdom and the British Commonwealth which contains some wise and venerable people selected for their great knowledge and ability, but mostly politicians who did so well in public life that they had to be removed from the House of Commons (The elected body) to where they could cause less damage, plus some actual hereditary peers (who get to stay there by being voted in by other hereditary peers), and of course senior public servants like old civil servants (whose devotion to a political master was so great it needed / deserved reward), former top police officers and chiefs of the general staff, and Norman Tebbit, Jeffrey Archer, and Andrew Lloyd-Webber.
This post has been deleted by its author
Let us hope that Sir Ian can do better than the current Lord Lea:
https://www.huffingtonpost.co.uk/entry/lord-lea-parliament-code-of-conduct_uk_5f312870c5b6e96a22b52125
"Peer Breaks Code Of Conduct Rules While Taking Code Of Conduct Training
Lord Lea of Crondall found guilty of "bullying" while meeting guest brought into give him "behaviour change coaching"."
Honestly I did not make that up, serendipitous timing.
Maybe they should ask (Baroness) Floella Benjamin for a lesson in how to count?
Along with perhaps Big Ted, Little Ted et al...
But you have got to believe in the right version of the correct thing that doesn't exist, There are no Catholic Bishops in the Lords and no Imans or Rabbi's are appointed to represent their faiths. I personally would like half a dozen Jedi's promoted to the Lords
The House of Lords is an anachronistic legislative chamber ...
Here I beg to differ with you. While you are correct that the new entries appear to show a certain amount of "thanks for your previous help, here's a place in the Lords in return" - or just "promoting people to somewhere they can't do any harm" - the House of Lords is an important part of our system.
If you look across the pond, you see that their upper house which is elected seems to have all the same faults that other elected houses seem to have. Most notably, a tendency to think about what is most likely to get you re-elected next time round rather than what is best for the country long term. BY having a non-elected house, they don't have that distraction and so have the luxury of long term thinking.
Their ability to actually create law is very limited, in fact I don''t think they can. All they can do is amend the output of the lower house and send it back. But because they don't have to worry about re-election, they can challenge (and in extreme, I believe they can block it) bad law proposed by the lower house who are looking at the next election. That is why Tony B Liar put so much effort into dismantling the Lords - as punishment for reigning in some of his worst megalomaniac tendencies.
The fact that each side rewards it's favoured ones with seats in the Lords does mean that overall they stay relatively balanced - we certainly don't have the wild swings that elected systems have. For example, we don't see the farce the other side of the pond have when one house is Democrat and the other is Republican - and no laws can get passed because the upper house will reject everything the lower house proposes "just because party lines".
As the old saying goes, what we have is far from perfect, it's just less imperfect than the alternatives.
The House of Lords is an anachronistic legislative chamber .. Their ability to actually create law is very limited, in fact I don''t think they can.
Parliamentary Bills can originate in either house and the Lords can delay but not block Parliament bills:
https://www.parliament.uk/about/how/laws/parliamentacts/
@ Simon Hobson
Agree completely. In Canada there was a movement among Conservatives to elect our presently appointed Senate. As with many ideas of the right imported from down south and unable to learn from history, this does not work. The US Senate was originally appointed and only later elected. It is now the area of gov't where lobbyists have their greatest impact. And in a rapidly changing world it's an impediment to gov't being able to move quickly and react to that change.
Should have imported your senate model from much further south, then.
Australian senators are elected from each of the states by proportional representation, six (sometimes twelve, it gets silly, don't ask...) of them elected each time around, for twice as long as the ones in the green house. Anyone who can muster about 15% of one state gets a seat.
Practical upshot is that it's exceedingly rare for any of the two dominant groupings to get an absolute majority, and compromise becomes a necessity. Sometimes it's with centrists, sometimes with fringe nut-jobs (witness the Motoring Enthusiasts Party), but unless an idea has consensus appeal, it's likely to be voted down.
Listening to leaders of a megalomaniac tendency (e.g. the one with the Italian suits, or the one with the eyebrows) rail against brutal reality has at least the entertainment value of watching a toddler throwing rubber toys out of the playpen, and for much the same reason.
Back in the day, some BASICs were zero-based, so DIM a(10) had subscripts that went from 0 to 9, others went from 1 to 10. As an aid to portability, BBC BASIC went full Spinal Tap and the above statement allowed subscripts 0 to 10, thus allowing 11 members.
"BBC BASIC went full Spinal Tap and the above statement allowed subscripts 0 to 10, thus allowing 11 members."
In terms of home/micro computers, that was pretty standard with BASIC arrays already. Both TRS-80 and Commodore PET, at least, did that.
This was done in BASIC, one of the easiest programing languages to read and understand. This is why PRINT was a life saver, but this guy didn't bother to print the new code and read it for just two lines, uh?
Had it been a decade later, it would have been quite easy to read the code in a computer screen?
But in the seventies?
PRINT and then bill the customer for the ink and paper.
Reminds me of the IBM 360 in my uni back in the 80's that kept crashing. Frustratingly coinciding with every time I tried to compile my COBOL program. Turned out there was a a critical full stop missing from my program and a bug in the compiler that couldn't handle this particular coding scenario and crashed the computer. Oops.
Faults like that could be beneficial to students as well.
My first year at university coincided with the introduction of a nice,shiny new Harris H500 super-minicomputer that the CompSci dept used for its undergraduates. It almost worked fine, just some minor little problems with the OS that meant that it Harris completely re-wrote it and installed the new OS (with a name change) over the following summer break, but I digress. Another nearby university also had purchased a Harris super-minicomputer, but this was a H1000 - the big boy of the range. However it kept on crashing just before course work had to be submitted, and it took the operators some while to work out why. It turned out that students had discovered that submitting a JCL command that added three variables and stored the result in a fourth variable (i.e. "A = B + C + D") crashed the OS.
Sadly it was only the big machine that had this fault; our smaller system didn't :-(
I remember one of colleagues submitting a compile to batch and sitting back to read the paper while it happened.
The he went "Oh Shit!" and dived for his keyboard. He'd forgotten to make one important tweak and figured he could get the source updated before the compile happened to save himself half an hour (yes, it took that long).
What I reckon happened next is that with impeccable timing he got the source updated smack between the initial compile to deck and the optimisation phase so, when it referred back to the source, things didn't match.
Only time I ever saw an entire IBM System/38 crash like that, those things were bulletproof. He insisted that it was a coincidence and I know correlation is not causation, but...
You reminded me of the brain dead Pascal compiler on the university mainframe that reacted to missing or wrong punctuation by throwing multiple errors for each line of the rest of the file... on the printed job report. 1 mistyped char in 100 lines could cause 1000's of lines of error and a quick dash between the shared printer and console to kill compiles to unblock the queue.
Long, long time ago, way back when, our CS lecturer managed 5 very basic errors in 5 lines of code. (mismatched brackets, missing semicolons, wrong variable name) We took great delight in pointing them out one by one and watching her read through the corrections without spotting the next one. Ended with her calling us smart arses and telling us to "F*ck off" and work on our assignments.
@Paul Shirley
"...by throwing multiple errors for each line..."
The PL/1 compiler on the Univac 1100 we used at university in the early eighties did that too. Although I suspect that it had a time or page limit, as it would stop after probably 100 fanfold pages (I used to have lots of scrap paper for mocking up my flowcharts and writing code - in fact, I still have a couple of those in amongst stuff I kept for some reason, but which will be finally get thrown away once I start clearing the shed).
Icon for "Why did I keep it again?
I remember working on a McDonnel Douglas mini at Freddie Laker's airline. They had 64KB pages and code and data had to fit into a page. Every change to a program had to be carefully calculated as to whether it would still fit in the 64KB page with its data records.
When I was teaching computer science a student couldn't compile a C++ program - it kept getting weird compiler error messages. The TAs etc. couldn't figure out what was wrong.
I looked at the program and the program was something like:
switch(c) {
case '/' //handle /
...
case '\' // handle \
...
case '-' // handle -
...
case '|' // handle |
...
}
etc.
Well a '\' at the end of a line is deleted along with the following new line before the compiler sees the code so this effectively commented out the next line of the program.
I always write a select statement first, then wrap the update in a transaction
Yes, BEGIN TRAN has saved my arse more times than I care to admit.
Though there was the time when someone (a friend, of course) forgot to COMMIT TRAN which left a lock on the database, and they didn't realise till alerts started coming in because the application servers couldn't do DB updates so weren't responding to requests. Oops!
Since then yours truly my friend always does a second COMMIT before closing the DB session in case the first one was forgotton...
Backing up the database before upgrades or major updates is also a good technique/habit as well. It's saved our bacon a couple times at [RedactedCo] when the vendor ran an update to their software which included a database update, and then found that our specific instance of their software install broke their update, which required a rollback.
Taking a snapshot of the VM is often not a valid way of backing up a database as several dev's I have worked with have found out.
If you want to secure a database use the database vendor or 3rd party tools to do the back up. If you are only working on a single table, copy it.
If you a re working on a key table then FFS get some dedicated time for the change, perform it on a database copy first and the perform the change in production when the database is not being updated. Its not just your updates you have to worry about. I implement systems with 1000's of active concurrent users. Its a major pain negotiating a downtime window but that's much so than trying to unpick the results of a data maintenance update that went wrong when 100'000's of other updates were taking place.
Last time I implemented a SQL Server based application shadow copying/ snapshotting was not supported by microsoft as a way of backing up an active database.
There was something odd in some old versions of Unix where the first sync didn't actually do anything immediately, it would sync when it could be bothered. The second sync forced the issue.
Digging around some olde searches, found this reference:
Evi Nemeth's sysadmin book sez:
sync; sync; halt
... the reason being that when the first sync returns, buffers
have been scheduled to be written, but aren't actually guaranteed
to have been written. The second sync (however) won't start
until the first completes.
There also seems to be some discussion about running it again giving the kernel time to flush to slower disks too. In any case, it's a legacy thing, but I suspect some old timers still do it out of habit.
As dmr put it (on a.f.c, dated 05/12/99): "If you actually typed "sync; sync; halt" then I can see the possible timing issue. However, if you were told to type "sync" and then do it again, this had to do with giving you a chance to ponder whether you remembered to do it at all the first time. Dennis"
People used to type sync<ret> sync<ret> halt<ret> to shut down the system; The second sync was there "just in case" because the first one didn't seem to actually do anything. Kind of a cargo-cult variation on sysadmining. My friend put them all on one line, separated by the ";" end of command character ... which, as dmr rightly pointed out, could indeed cause timing issues if the first sync hadn't finished before the second one started up. Thus my "unclear on the concept" comment.
While I still know a few folks who use sync<ret> sync<ret> halt<ret> to shut down the system, I don't really recommend it. This is all legacy stuff now. Instead I suggest shutting down your system according to the instructions of the maintainers.
Has it really been over 7 years since Evi went missing? Where does the time go? ... RIP, lady. You are still missed by many.
> People used to type sync<ret> sync<ret> halt<ret> to shut down the system;
Rather:
sync # Then wait for the system to go visibly quiescent
sync # Wait likewise
halt
> Kind of a cargo-cult variation on sysadmining.
It was an attempt to get a clean shutdown on a system that provided no way to guarantee one, because sync(8) wasn't itself synchronous. On some systems it still isn't.
Linux's sync(2) man page sums up the situation there: "According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)"
You know, actually this very condition is embedded into many of the constructed queries for the application I have to work with.
Only because the query builder just blindly concatenates the SELECT/UPDATE/DELETE ... with the conditions prepended with AND, no matter if there are any to add or not.
SELECT foo FROM bar AND foo=1; --not valid without WHERE
SELECT foo FROM bar WHERE; --not valid if no conditions
SELECT foo FROM bar WHERE 1=1; --valid
SELECT foo FROM bar WHERE 1=1 AND foo=1; --also valid
Ugh.
The example here definitely wasn't SQL.
However yes, such an option would make things slightly safer when writing ad-hoc SQL data changing statements. I am in the habit of typing out the where clause first, then the lines that do the update or delete. I practice paranoia for good reasons...
Just wondering because if all he did was add the lines to set the value to zero and write back the record, there should be a copy of the pre-update data in the dump file. Possibly not a lot of help, but sometimes you are blessed and have a "last updated" date/time on the record which can be used to find any updates made since the backup...
Of course, this is back when every byte counted so adding "helpful" attributes which were rarely used was considered wasteful.
This post has been deleted by its author
In this case its just a label rather than actually being line 10
Obviously not a cricket fan
Glenn McGrath (AUS bowler) v Eddo Brandes (Zimbabwean batsman)*
McGrath: Why are you so fat?
Brando: Because every time I make love** to your wife, she gives me a biscuit!
*Amongst various attributions
** You can be sure he didn't say make love
I worked for a company who had a similar tale where we ran a competition for a client. The Developer who wrote the competition accidentally forgot to remove a line of test code when the site was deployed live. The result was that at the end of the competition there were some 50,000-odd entries - all with the exact same name and email address. The test code had basically copied the first line of the DB into every entry when a submission was received.
Now - under normal circumstances, you could have covered this issue up because you could have just said - OK then, that first guy/gal wins the prize.
Problem was - there were 5 prizes...
I believe they extended the competition deadline by a couple of days, so if you entered after the deadline, you stood a much better chance of winning.
Mainframe systems often used hierarchical rather than relational databases. Each database had it's own API. SQL was not commonplace.
The data was generally stored in flat files, and the DBMS, was so slow that it was totally impractical to use it if you needed to process every record in a large table.
For speed and efficiency, it was common practice to reverse-engineer the structure of the database files and edit them directly from your application rather than use the DBMS. Not just in the 1970's either. I was working on banking systems that did that right up to Y2K.
And if the mainframe you were using did support a relational database, the licensing costs where often so high that it was cheaper, even including the womanhours spent writing it, to implement a relational database on top of the hierarchical database that you'd already paid for. That was a fun project.
Back when I was a coal face programmer, coming from a VB background, I got caught out by this C error 1 time too many:
if (a = 1) {
// Bug: code here always executed irrespective of 'a'
}
Of course the first line should be: if (a == 1) {
Before compilers cottoned on this common mistake and issued a warning, I started reversing the variable and constant, so:
if (1 == a) {
because if I accidentally used a single = the compiler would catch it.
Oddly I never convinced any other code to follow suit. They just didn't like it.
I understand the reasoning behind reversing the operands, I just don't like it. It doesn't scan well in my head.
In any code base I touch these days (usually C++) the "assignment in conditional expression" warning is promoted to an error.
And just don't get me started on the if( type variable = expression; variable ) syntax of C++ these days. I'm feeling nauseous just thinking about it.
Indeed. The problem is, I think, that while "==" is commutative mathematically, psychologically it kind of isn't. Its left operand is the unknown quantity I'm testing; the right one is the known quantity I'm testing it against. Thus, "if (1 == x)" reads as though I'm inquiring into the value of 1.
The same is true for inequality operators, by the way: I'd never write "if (5 > x)". Then again, there'd never be a reason to do that. "==" is the only one of C's six relationals that has any reason at all to be reversed -- and at that, only when exactly one of its operands is an lvalue.
Many years ago I had to use a vendor provided custom language for application development... I've manged to erase the name from my mind, but it ran on VAX VMS systems...
The interpreter didn't cache values, it was all immediate by reference therefore there was a distict difference between the two statements:
A = A + 1
and
A = 1 + A
The first would operate as expected, therefore starting with A assigned the value of 5, after the statement A would have the value of 6.
The second, on the other hand, would assign 1 to the A and then add A to itself, always producing the result 2 no matter the starting value.
In reality what the first statement did was to assign the value of A to A and then add 1 to this afterwards. Slightly inefficient but it worked.
That was not an amusing "bug" to track down and find. Erm, "feature", that's it, definitely a feature and absolutely not a bug. We weren't sure what to call it then, it caused a bug in the application but was it a bug in the interpreter? It wasn't operating as expected in line with other environments.
> "The interpreter didn't cache values, it was all immediate by reference therefore there was a distict difference between the two statements:"
That's a shocker! And people wonder why programming is a lot harder than it should be.
I gave up coding when I realised I was still solving the same problems that I had started my career fixing 20 years earlier, e.g. writing a UK formatted date to a database, and reading it back later only for it come out in US format!
Even this very week I've come across the same issue using SharePoint. *facepalm*
There is such a nice bug in powershell/wmi still true today... Run
Get-WmiObject Win32_QuickFixEngineering -ComputerName $Computername
If you get the latest windows updates installed you see that some updates have no date listed when they were installed - and others are actually wrong.
There is a bug where the query returns Day/Month/Year value, but the expects US Month/Day/Year (or the other way around, cannot remember), so anything installed after the 12th in a month would have no
t date listed. Which then was my hint why my script for checking when the last updated was installed didn't show the values I was expecting: How can an update be installed on 6th of December when we have 12th of June?
This query works fine locally though, since it uses the local country setting, it only fails when querying a remote computer. Luckily it can be fixed, I reordered the date string to be "yyyy-MM-dd" before re-feeding it into get-date, which leaves no room for confusion.
This post has been deleted by its author
Thank you. I've been coding in C and C++ for over 30 years. It's been rare for me to see that ordering, and when I did, I wondered why it was "reversed". But I see your point; it does make the difference between assignment and comparison clear. Only failure I see is for 'if( a == b)", where it can be a mis-assignment even when reversed... but most of the time, it'd let you catch mistakes.
Ouch, that's harsh!
I thought it was bad enough when Windows volumes went past what the number of bytes that could be represented in a signed 32 bit integer. As a result many applications failed to install on larger drives if the amount of disk space remaining wrapped round in the negative values of a signed 32 bit number. What was particularly annoying is that this affected multiples of the is value therefore having 5GB free was OK, but having 3GB was not because that was returned as a negative number of bytes. Something like that anyway... it was a long time ago...
... worked on a project where we had a database set up by two people (nameless to protect the guilty, as ever).
Anyway, on my first use fo the database I accidentally entered some incorrect data in two fields. I couldn't find the 'undo edit' button, or the 'exit without saving button' to return to the original data, so sent the two an e-mail, along the lines of:
"Hi, I was using the database and accidentally entered incorrect data in these two fields. Couldn't find a way to return to the original data, can you re-set, please?"
But answer came there none.
Then the database went 'down' for a couple of days, and came back up again.
It seems that these two had set up data base access for everyone on a 100 person project, so that anyone could edit any field with the actual edit happening and being saved in real time, and no back-ups.
I can remember a time when the hardware engineer pulled the wrong drive and trashed the raid 5 array. NT 3.51
The restores did not work.
This was one of my first roles in desktop\server support, and I spent the night rebuilding the server from scratch as the actual server guy went home. (The server guy was not our normal server guy who was on holiday). The data volumes were ok, it was just the OS volume that would fail to boot fully after the restore.
I then spent some more time looking at the backups, and the actual problem was that the admins weren't removing the home drive shares when removing user accounts.
This cause the netlogon process to take too long to start, which then caused the follow on services to fail to start.
The server guy wasn't asked back again.
This post has been deleted by its author
Posted before, but..
A few years ago, my boss wanted to open up some of our computers for people to use the internet. A sort of internet cafe, without the cafe part. As he didn't want people hogging the machines, he wanted some way to kick them off after a predetermined time..
Being a keen c++ programmer at the time (still am really, just don't get time for it), and having recently found out how to write Windows Screen Savers )for another project, can't recall much about it though).
So, I knocked up a screensaver that when instantiated, would do a forced shutdown and reboot.
I should point out at this time that when you run the initiatesystemshutdown API on Windows with the Forced and reboot options set, windows will reboot the machine, and will not get you the option to save your work.
I had the main screensaver working, and was working on the code to register it as the system screensaver, and, IIRC, a control panel applet to set some options.
I had just run the install code to test if was setting the system screensaver correctly, and got called away to sort something out. I hadn't actually saved anything, and, as a result, when the screensaver kicked in, I lost everything.
I didn't recreate it. I had always had reservations about doing it, particularly would we, as a department, be liable if an employee from another department did work on it (we had signs everywhere saying the machines were for general internet browsing only), and lost work as a result. My boss quietly abandoned the idea when I pointed that out to him.
We do have a product installed now on some computers that does the same thing (just using it's own timing mechanism rather than installing itself as a screensaver). It wasn't my decision to install it, but at least the new one makes clear to the user what will happen, and when. As such, if a user users the computer, leaves it and loses work as a result, it's their responsibility, not ours.
Usually, someone without a lot of extra space, such as someone on an old 1970s-era computer. I don't know what the disk situation was like on that, but I'm guessing it was not easy to find twice the disk space to make a backup of the database file and that, if you did, it would take quite a long time to make the copy. Now depending on the size of the file, it's possible they could have made an extra external backup onto other media, but that also might have taken a while. When faced with a situation so seemingly easy (a single SQL statement does it in modern times) with a backup requiring nontrivial effort, someone might trust their intuition for proper coding, which probably worked just fine the last hundred times. Then uh-oh.
There was a time when I'd see a user laboriously working through a repetitive bulk update using a screen form and say "We can save you hours of work by doing that as a ${whatever} script".
I've since learned to be more circumspect. If all goes well, you'll earn some gratitude, but you'll have to do it again every time. If the update turns out to be a lot more complicated than the user's explanation of it, you may be in for a long night. And if something goes wrong because you make a mistake, you'll carry the burden of guilt to your grave.
Ah yes, I remember Business BASIC. My first job after college was at a company that used Business BASIC on Data Generals. I was horrified to find that their exception handling was to deliberately cause a divide by zero error.
So a customer would ring up to say they had an arithmetic error at line XXXX. You had to pull out the printout of the program, work out how it got to that line, ask the customer to print out the values of involved variables and decide what the problem was. Then get the customer to reset some variable and issue a GOTO to get it restarted.
How did they get away with it?
At our place we've all been in the position of being asked by our PHB to apply an untested tweak to a critical live system. It happens approximately once per project. Those of us with an ounce of professionalism and self respect decline to do so, stating our reasons in writing.
The PHB then works their down the chain until they find somebody who does what they're told. The live database or whatever is then destroyed, as per instructions. The rest of us then hear about the problem, recall the dodgy instruction we declined to carry out the previous day and see what can be done about recovery.
My favourite was the utter disappearance of the data files for an Oracle instance. It turned out a couple of entries had been removed from /etc/fstab, because for reasons we never got to the bottom of the PHB wanted those entries removed from that file and didn't want backchat about it. At least that one was a quick recovery.
Ah. I remember using a Nova 4 for X-Ray crystallography. The rack-mounted beast sported a whopping 10 MB hard drive with a replaceable platter and it had a teletype user interface. It got the job done, though the computer bit the dust a couple of years after I left. Those were the days: high voltage, radiation, and sleep deprivation.
I'm reminded of my ears days as SQL Server admin dealing with an in house application where the user management had neve been written so all adds and changes involved ad hoc SQL queries. I was asked to change a user's name and forgot to put a WHERE in the SQL update query, giving all 40 odd users the samw first name. Fortunately it was a lightly used system so I just restored the users table form the hourly backup.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
