Tales from the shop: When errors compound...

While working to a deadline recently I encountered a really strange GPF. I'd moved a procedure from one APP (in a large multi-DLL system) to another app, and the move necessitated some code changes. After I'd compiled all the affected apps, my executable GPFd. 

I forget when SoftVelocity began shipping the debug version of ClaRUN.DLL, somewhere in Clarion 8 I think, but it's been a godsend. Compile your app(s) with debug info on, use the debug ClaRUN.DLL, and if you GPF, instead of a difficult-to-read stack trace with a bunch of memory addresses you get actual line numbers that take you directly to the location of the GPF.

Except in this case the stack trace did not contain any source code line number references. I double-checked; yes, I'd compiled all the DLLs with debug on, and I was using the debug runtime. 

I went back over my code changes, thinking perhaps it had something to do with the procedure having moved between DLLs. I restored the original procedure and renamed my new one. No joy. 

Finally I saved my current work and went back to the previous commit (the entire project is versioned in a Git repository). And I started reintroducing my changes. As I copied back in some class changes I'd made I suddenly had hundreds of compile errors: the compiler was completely confused and unable to locate included files that I knew were available because I could open them using the redirection file. 

The only change I'd made was to the source files for a class that was a MEMBER of one of the apps. This isn't something I do very often; as much as possible I try to keep my classes independent of any APP data, and if I do need a derived class with APP-awareness I usually declare those classes in embedded code, not in standalone source. 

Eventually I discovered a stray period. It was inside a property name! Instead of

SomeClassProperty                 long

I had typed

SomeClass.Property                 long

This is not how you make the Clarion compiler happy. I suppose it simply took the period as an END statement and acted accordingly. Stray ENDs lead to bad endings. 

After fixing this bizarre typo I was able to compile the DLL and run my app. All was well!

Until the next morning, when I tried to run another executable and got the same GPF that I'd encountered at the very beginning! I knew (or thought I knew) that it couldn't be the stray period in the class because the class now compiled. 

But I had copied some global INCLUDE statements in the course of moving the procedure between APPs. And one of those was the include for the class header that had a MEMBER statement pointing to a specific APP. 

Let me be more exact: I had a global include referencing a class's INC file, and that class's CLW file had a MEMBER statement that said the class belonged to a different app. Everything compiled just fine, but when I tried to run the app everything asploded. 

I didn't bother trying to track down the exact reason for the GPF; I just removed the unnecessary include statement, compile the DLL in question, and was  able to run the second app. 

Ordeal over.

Lessons learned

These aren't so much lessons learned as firm reminders of things I already knew. Some days those reminders arrive with more force than other days. 

• Naming conventions are your friend - if I'd been clearer about the name I used for the class that had a MEMBER statement associating it with one app, I likely never would have made the mistake of including it in a different app.
• Lack of sleep is never your friend, and bad things are more likely to happen when you're overtired.
• When making significant changes, compile early and compile often. I might still have tripped over the include problem, but if I'd compiled just a bit earlier in the process I would have isolated the period-inside-the-class-property error sooner.