Sounds like you have a dead key enabled. If you press apostrophe, then another key, do you get a combined character that includes an apostrophe or a similar accent?
Yeah..one of the most obscure ones I dealt with very early in my career was a compiler bug. The details are lost in the fog of my brain, but I remember debugging it to the point that the length of the name of a variable in a certain circumstance caused the program to fail. I changed the name, and it started working. I changed it to something else but the same length as the original name, and it failed again.
It was a good lesson in debugging, and in being willing to question your tools.
-D/a
Three times now this has happened to me, every few years, and using different versions of SAS (a statistics package):
The most recently saved program files (which are ordinary ASCII text) are all overwritten with hexidecimal FF characters. However many recently opened filenames are set to be displayed in the File menu, all of them will be overwritten. Nothing but 255’s throughout.
This is such a disastrous bug that I have even gone to the trouble of getting our IT folks to set up folders on our network in which I have rights to write but not to edit files.
The folks at SAS Institute say they have never heard of this problem before, and I have not the slightest idea what I might be doing wrong.
Well, you have to understand that a keyboard has only, say, five pins running into the motherboard, and each letter is a combination of those pins being on and off. A poorly built keyboard can send ‘ghost letters’, generally along a diagonal line. https://www.microsoft.com/appliedsciences/AntiGhostingExplained.mspx
(Some of what they talk about is the precise reverse of your issue. I suspect that your keyboard is sending extra information, which is then triggering the anti-ghosting feature of the keyboard driver.)
I see this sometimes on laptops, as the circuitry under the keys is more fragile and easy to screw up. All I can say is try to mess with the sensitivity settings of the keyboard, or try a different distribution.
Try this LiveCD, see if the problem is the same.
This is a weird and flaky issue, of the kind that makes people go ‘hmm’ a lot.
Interesting article. I was vaguely aware of these kinds of limitations but I didn’t know the details.
One thing though – this isn’t a flaky problem. It’s 100% consistent and reproducible, and only happens in Linux (though I haven’t tried other distros like you suggested). Could be that the Linux kernel is more robustly rejecting what it sees as rogue keypresses, whereas Windows just accepts them.
Just a quick thought, if you have any peripherals connected (external mouse, keyboard, etc.), they could be the culprit. Even some Bluetooth devices - I have a Magic Trackpad which connects by Bluetooth and it can wake up my closed MacBook Air. If the computer is connected by Ethernet cable, you might have the “Wake for network access” option turned on.
I’ve told mine here, before, but: basically, I was working on our computer at home when something :::blipped:::… and the monitor displayed everything reversed right to left. Not rotated (like you can sometimes do with ctrl-alt-arrow keys)… it was literally MIRRORED right to left.
I spent a LOT of time trying to trouble-shoot that problem, including uninstalling / reinstalling the drivers (and let me tell you, it’s a rare treat to try to navigate those menus when they’re REVERSED). I turned the monitor itself off and on. Finally it occurred to me to try the monitor on a different computer - and it was reversed THERE as well. So, problem definitely was in the monitor, not the computer.
Sony wanted more to service it, than a new one would have cost. So I was researching a new monitor, when the one thing I had NOT tried popped into my mind: UNPLUG the damn monitor. Yes, full-on unplug, not just turning it off.
It worked perfectly when I plugged it back in.
In hindsight, this was probably what was going on with other computer misbehavior prior to that: the computer would seem to boot, but the monitor would get to that “I’ve got power” glow it does right before it actually displays anything… and no further.
This happened a number of years ago. The company I was working for had a server running Windows NT. We had a program that I had written that logged into a customer’s website and scraped info off a webpage and entered it into a report. It was important that it run every morning, so we made it a scheduled task on the NT server.
One morning the report was not updated. I checked and found that the task had not run. It was easy enough to run it manually so I was able to solve the immediate problem but then I had to determine why it hadn’t run and to make sure that it didn’t fail again.
I discovered the immediate cause pretty quickly. On NT, when you created a scheduled task in task manager you had to enter the ID and password for the system context that you wanted it to run in. When I checked the task it said that it needed the correct password before it could run. Apparently the password that it had stored wasn’t valid. This was strange since normally you just enter it when you create the task and from then on it runs at the scheduled times.
I had operations get the password book out of the safe and enter the password. It then ran normally every day as before, until one day a number of months later it failed again and once again required reentry of the password. They again entered the same password and it ran fine for a number of months.
It was maybe the third or fourth time that this happened that I joked that “it must be because of daylight savings time” since we had changed the clocks the night before. It was a joke and I never seriously considered the possibility since it didn’t make a lot of sense. The problem was that the password that task manager had stored was somehow becoming invalid and had to be reentered. How could that possibly be related to daylight savings time?
The next time it happened, probably because I had made the joke the last time, I noticed that it once again had happened after we changed the clocks. At that point it dawned on me that, as far as I could remember, it had been happening about twice a year, so it was conceivable that the other times were also due to the clock change but no one had noticed. Why would you?
I began to research it and found out what was going on. I’m going to spoiler the solution in case anyone wants to see if they can figure it out (or find it - it turned out to be a known problem and was being discussed on the web at the time).
The natural assumption is that, since this was a scheduled task that runs at a certain time, the clock changes were screwing up the schedule somehow. This is where it becomes subtle and esoteric. It had nothing to do with scheduling or the time that the task ran.
[spoiler]When you created a task in NT’s task scheduler, you had to enter the user ID and password for an account on the computer so it knew the security context to run it under. If the password is wrong it won’t run. The problem with this is that, in order to run it every day (or once a week or whatever) it had to be able to sign in the task each time, so it had to store the password.
This is an obvious security problem, so the password is stored on the disk encrypted using an algorithm known only to the task scheduler software. This algorithm generates a random encryption key for encrypting and storing the passwords and of course, since it needs to be able to generate the same key to decrypt, it has to use the same seed in the random generator each time. I don’t know all of the details of what went into that seed but, among other things, it used the time-date stamp of a particular system file under the assumption that that stamp would never change.
This would be a safe assumption but there was one problem. Instead of calling the API to retrieve the UTC time-date stamp stored on the disk, it called the higher level API which gives the time-date stamp converted to local time. That means that when the clocks changed it tried to retrieve the password using a decryption key generated using a time-date stamp that was off by an hour from when the password had last been entered. Therefore the password it retrieved was wrong.[/spoiler]
Here’s my strangest one: the Earthlink shortcut.
I have to say, I’m extremely skeptical that the mere presence of a shortcut on a desktop could have caused that. Are you sure that it wasn’t someplace like the startup folder rather than the desktop?
I tried both of those issues. I have no Bluetooth devices and the Bluetooth on my laptop is turned off. The “wake for network access” option is turned off, and I’m wireless both at home and at work (problem occurs in both places). I’m happy to try anything else if you can think of it, though.
I’ll post two, because one is to do with development so I’m not sure it counts.
- I have a laptop that seems to habitually change its resolution to something slightly narrower than its native screen size for a split second, then back again, some number of seconds after I first turn it on. It doesn’t do any harm really, unless I have a fullscreen application running that can’t cope with having to suddenly reallocate all its stuff - then it tends to crash. I seem to recall this started when I first installed the software for a wacom tablet some time ago. It does it once every time I turn the thing on.
I realise that in the grand scheme of things, and particularly compared to the OP’s, that’s not that obscure, but I also have this:
- A game I’m writing has, in probably a few hundred hours of play, once, ever, experienced a problem where after finishing a level, all the text in the game prints without spaces (Like, “to select a level press ‘d’” prints as “toselectalevelpress’d’”). Carriage returns still work, as well as all other strings. This happens for hardcoded string literals as well as stuff loaded from a file. And the kicker? It happened for every string, except one on the title screen (I think it was the copyright notice, which is hardcoded along with a bunch of other stuff that did experience the problem). I never figured out what could possibly have made that one different, because when I restarted the game the problem was gone, and it never came back. The sad thing is, this bug is so low down on the list (it pretty much never happens so it’s very hard to track down, plus it’s not really worth it because even if it does happen it’s not like it crashes or deletes your save or something) that I’ll probably never find out what happened that one time.
That’s what I’d expect from a hardware problem based on signals generated by a keypress. Download a different ISO, see what happens. There is a slim chance swapping the keyboard out on your laptop could fix it, but I’m curious to see what a different ISO does. It might just be a specific hardware/software version interaction.
I used to have a server that only booted when I turned it 180 degrees upside down. It’d run fine right side up for months, but it wouldn’t boot. I blame bad capacitors on the motherboard.
On that Macbook Pro: Does it happen at roughly the same time every night/day? Probably night time, but I’d also guess it could happen at roughly 8:30-9:30, and sometime around noon. Alternately, does it seem to coincide with your boiler or refrigerator kicking in?
If so, it’s like a telephone ringing.
The voltage to your outlet drops dramatically, then pops back up, like a brownout. This makes some PCs power up. Is it on a surge suppressor?
Years ago, I was helping support a COBOL program that, among other things, took a random 1% sample of an input data file, running every night.
Very rarely, it would select all of the records of the input file. On rerun, of course, it would be fine. It being COBOL, there weren’t a lot of options for what could be going wrong.
Finally tracked it down to the program that was supplying the random number. The generator of course took a seed value on it’s initial call to establish the sequence. The standard was to use the system clock time (as HHMMSShh (hh is hundreths)).
Turns out that, for some reason, the random number module was set up to always return a zero if the initial seed value was zero (no idea why, presumably whoever wrote it had some weird requirement). And, of course, the program was part of a job-string that kicked off such that this program would run right around midnight. And, once in a blue moon, the call to obtain system time would land exactly at midnight. The program would always get zero as the “random” number, and that would compare as < .01, and all records would get selected.
We fixed it by adding 1 to system time before the seed call.
Definitely does not happen at the same time each night, and the boiler and hot water heater are gas powered. It could correlate with the refrigerator, I’ve never tracked that. Good idea.*
OTOH, it also happens at work, which is in a lab with approximately 1,000 freezers/refrigerators/incubators/PCR machines/other power draws - the voltage supply there should either be extremely noisy or smoothed out by averaging.
Of course, testing this idea would require me to stay awake in the kitchen for hours without dicking around on line, since the laptop needs to stay closed. Worth it in the interest of science, of course, but maybe not until after my current grant proposal is finished.
Yes it does. Well that explains that. I’ve never heard of dead keys before.
Rather annoying.
A dead key is like a shift key but you release it before pressing the second key. There are a lot of them in the US Extended keyboard, reachable via ‘option’ plus just about every key on the keyboard. What keyboard layout are you using?
Well, there’s a quick way to test: don’t plug it in. See if it boots up when not plugged in.
Aha! That, I’ve already tested - it does not spontaneously wake up when not plugged in. I didn’t think of that as being diagnostic, since I was assuming that plugging it in changed the power saver settings.
Anyway, if I get sick of grant-writing tonight, I’ll put the computer to sleep and open the fridge door to force the compressor to kick in. I’ll report back.
Thanks for the ideas!