Can Anyone Explain My Observations?

1

Hi All,

Yesterday I returned to a project that I had working on Tuesday.

When executing, the form displays, when I hit the OK button, I get an immediate AV.

For reasons I will not bore you with, in the situation I am using this code, I have no debug. (and when I have debug, no AV).

My only debug tool is Show message , and no matter where I put the show message, it did not execute, just got the AV.

I thought the .dfm was damaged (because this is usually the cause when I see something like this), so I went back into the repo and restored it, but still the AV.

I made a change to the Form to force the .dfm to change. (I had to try anything)

I then started getting my Show messages - I could then put show messages until I located the bug, which was not in the form.

Why was Delphi doing this?

There was definitely a bug, but it was not in the form. I think if I had Debug, in this case it would not have helped.

How could I have found this problem in something less then the 3 hours I burned?

(or should I just be happy that I eventually found an obscure bug that might have shown itself at a more inconvenient time).

regards

Brian

2

Hi Brian

Have you tried deleting all the dcus and rebuilding the exe?

I have had the situation where I am testing away without using the debugger and get errors that indicate that some of my code is not executing at all. It appears to be ignored or goes elsewhere.

When this happens I normally run the debugger and follow the code through and this normally executes the ‘missing’ code and the problem is resolved.

I have found that deleting the dcus (that is doing a clean) before rebuilding (not recompiling) fixes the problem.

This is certainly a worry for me as it seems that a simple recompile may not always generate the correct code.

Hope this helps.

Regards
Graeme

s wrote:

3

I have had EXACTLY the same problem as Graeme, going for a couple years at least on XE6.
The compiler is fully loaded with all sorts of bugs anyway, but this one was quite annoying, and highly intermittent.
It just should not have been happening the way it was.

Sometimes, I might get it approx every 3rd or 4th time that I compiled. ie A LOT.

This might keep up for a couple of weeks, then I would see very little of it, and then… …
I found it helpful to delete the old .exe file, before compiling the new one.

I have had a regular problem with another one too.
The silly compiler sometimes will not flag (some) variables that don’t exist.
eg I want

var
counterI: integer;
begin
anotherVarI := counterI + somethingElseI;
… …
In a bit of speed racing and getting on with it, I do a simple typo like >>

var
counterI: integer;
begin
anotherVarI := cou nterI + somethingElseI;

Neither “cou” or “nterI” exist, yet the stupid compiler runs right over the top of it, and DOES NOT FLAG AN ERROR.
When you run through it at runtime, it crashes immediately. I have seen it happen dozens of times.

Once, I had a deep nest of: if if case if if if etc.

It was well tested, but obviously not exhaustively, because the errant line crashed out some 6 months later

The compiler isn’t compiling the code properly, and is creating unsafe code that could bite your rear end at any time in the future.

I might have had confidence that everything was fine, and sold my product to lots of people, who paid lots of money,

Then 6 months or whatever later, they all start failing one by one.

That might just be embarrassing, or it could possibly have dire effects.

It needs to be fixed by Embo. It will be easy to fix.

Just get the compiler to compile properly. Like it should. That is the job that it has got.

Cheers to all,
John Walker

4

Do you normally compile or build? – Compile specifically is very flaky and can produce these problems often, but Build is usually clean for me.

Alex

  • Sometimes, I might get it approx every 3rd or 4th time that I compiled. ie A LOT.
5

Are you not able to use something like MadExcept or Eurekalog to give you a stack trace.

Also, clean up your library/search paths. This is one of the reasons I almost never use the library path, but rather add what I need to the project search paths. That way I know for sure what code my project is referencing. I’ve had issues before where my exe was compiling with one version of a library, while another was loaded in the IDE - so forms got messed up due to the differences in the library versions. It was all very confusing and forms behaved strangely and the project crashed often. I fixed it kinda by accident when cleaning up my library path.

So as other’s have mentioned, worth doing a clean, and then going explorer and check for left over dcu’s etc.

2 Likes
6

Hi,
On a side issue.
Have you tried CodeSiteExpress (via getit)

Install that, then in your dll (I am assuming a DLL)

uses
  ... (stuff)
  CodeSiteLogging,
  ...

{$R *.res}


begin
  CodeSiteManager.ConnectUsingTcp;
  CodeSite.Send('MyDLL Loaded');

end.

Probably eventually with appropriate $ifdef’s

Then codesite.send(stuff) as required in your other code.
It can dump quite a lot of things, eg objects with published sections.

You can turn the actual logging off at runtime with
codesite.Enabled=false;