Bad build a mystery

[Sherlock 663]

3 minutes ago, Bill Meyer said:

When you are dealing with a large legacy project, however, untangling years of ... interesting ... coding takes time.

I totally understand. That saying should always be delivered tongue in cheek.

[A.M. Hoornweg 144]

Just an idea how you can quickly find out which of your units is broken:

 

Units normally get initialized in the same sequence in which they are entered in the *.dpr file. 

 

So... my idea is to create a new empty "diagnostic" unit. Let it use only the "windows" unit and nothing else. For the rest, keep the interface section empty.

In the implementation section of this unit, write an initialization that simply shows a "hello world" messagebox.

 

This initialization will only execute if none of the units that initialized before it caused the program to terminate.

 

So... Just start playing with the position of this unit in the USES clause of the DPR file. For starters, place it somewhere in the middle. Compile, and see if the messagebox appears. If yes, move the unit halfway further down in the USES clause. If not, move it halfway further up. See, we're doing a binary search here...

 

Repeat this process until you have found the exact position where the messagebox no longer appears. It shouldn't take more than a dozen attempts.

 

The offending unit will be the one right before the diagnostic unit. It's either that unit itself, or some unit which it depends on and which isn't in the uses clause.

 

[A.M. Hoornweg 144]

I recently had the case that an update of a third party library "patched" a VCL routine and replaced it with a different one for speed reasons, only the new routine turned out to be buggy. This caused a program of mine to suddenly behave erratically.  It took me and the author of the library quite some time to figure it out...