PDA

View Full Version : It cannot be, yet, it is...


Keapon Laffin
10-25-2004, 01:14 AM
Right now (well, not exactly), I am staring at an programming impossiblity.

Something which shouldn't happen just did.
Something which I know, for a fact, without doubt, cannot happen.

And it cannot happen because I specifically wrote the code to ensure that.
But there it is.

Mocking me.

Defying my code.

I'm somewhat stunned, and in shock.
A programming anomaly, that just... cannot be.

I'm sure that eventually, I'll discover the logical error causing this.
But for now... I'll just remain... flabbergasted.
:confused:

iampunha
10-25-2004, 01:27 AM
If you posted the code and the unexpected result, I'd hazard a guess you *might* run into one or two people on this site somewhat familiar with code who might be able to take some sort of guess at what might have happened.

But that's just my opinion, I could be wrong;)

As long as it isn't a homework problem or something...

Keapon Laffin
10-25-2004, 02:02 AM
If you posted the code and the unexpected result, I'd hazard a guess you *might* run into one or two people on this site somewhat familiar with code who might be able to take some sort of guess at what might have happened.
Were it that I could.

Unfortunately, the code is a mite complicated, plus I'll probably be breaking some confidentially agreement.
;)

Mangetout
10-25-2004, 04:18 AM
I feel your pain; this happens to me every once in a while.

The best one I saw was in a Delphi (not my choice, don't ask) application - the thing I had (until then) totally failed to grasp with Delphi is that after executing the Form.Close method, the form is just hidden from view - it isn't unloaded and it can still execute event code.
For example, if you have a data bound control with an OnChange event, moving the record pointer in another form causes the data to change in the (invisible) bound control - executing the code in a form you thought wasn't even part of the picture.

Keapon Laffin
10-25-2004, 04:48 AM
I feel your pain; this happens to me every once in a while.

The best one I saw was in a Delphi (not my choice, don't ask) application - the thing I had (until then) totally failed to grasp with Delphi is that after executing the Form.Close method, the form is just hidden from view - it isn't unloaded and it can still execute event code.
For example, if you have a data bound control with an OnChange event, moving the record pointer in another form causes the data to change in the (invisible) bound control - executing the code in a form you thought wasn't even part of the picture.
Ha ha ha. Don't be ashamed. I'll admit that I've coded in Delphi before.
:o :p

Yeah, thats a bit odd. I would also have expected the form to be unloaded.
Ah well.

Derleth
10-25-2004, 05:03 AM
Unfortunately, the code is a mite complicated, plus I'll probably be breaking some confidentially agreement.Then post the minimum compilable piece of code that demonstrates the underlying problem.

(Damn, I'm back in comp.lang.c. I guess the moral is that techies don't commiserate, they troubleshoot.)

My story is hair-ripping as well. I was doing some work in x86 assembly and using the misdesigned div opcode. (No, not the botched fdiv, this was completely integer work.) The x86 div opcode, instead of simply diving one register by another and putting the result in a third like all sane ISAs do, divides the edx:eax register pair by the single operand, and then puts the quotient in eax and the remainder in edx. This implies that edx, a completely unrelated register as far as the current computation is concerned, must contain data that can be validly used as an extension of eax.

If it doesn't, your program will fail. It will fail in mysterious ways that give you no useful diagnostics until you compile a C program and look at what the compiler spits out to do the simple job of dividing two integers.

You cannot imagine how long I looked at that code, trying to piece together what made it crash like a drunken freshman. And x86 assembly is not pretty code.

Intel, AMD, and all of the other clonemakers are chained to a 20-year-old ISA that was a bad idea at the time. I haven't used either of the 64-bit x86 ISAs, but I rest assured that they can be no worse.

Small Clanger
10-25-2004, 05:22 AM
Something which shouldn't happen just did.I do a lot of work in Oracle Forms*, boy do I know what this feels like.

C'mon show us the code.



*and Reports :eek: when I can't wriggle out of it.

Keapon Laffin
10-25-2004, 11:06 AM
I do a lot of work in Oracle Forms*, boy do I know what this feels like.

C'mon show us the code.

*and Reports :eek: when I can't wriggle out of it.
Ughh, I hate designing reports. Especially when you've set everything nicely and the client wants another decimal place. GAHHHH :mad:

Anyways, sorry, the code is question comes from a few different modules, plus I'll have to explain everything, and I really don't feel like doing that.

I'll probably just step through it tomorrow.

zoid
10-25-2004, 04:46 PM
Ages and ages ago I was writing a program in C which contained a line something like,

x=x+1;

I put a value watch on x and stepped through the code line by line. When the above line executed, the value of x went from something like 135 to something like 432,367,543,234,765!

The Microsoft support tech I was on the phone with solved the problem by asking me to turn off a “conditional” compile feature and re-compiling the code as a whole. It worked fine after that. The thing that killed me is that the tech said:

Oh that feature never works, but it’s turned on BY DEFAULT!