-1

Sometimes my program freezes. If i click 'Pause program' it shows me this:

ntdll.RtlUserThreadStart:
773301C4 89442404         mov [esp+$04],eax
773301C8 895C2408         mov [esp+$08],ebx
773301CC E9E9960200       jmp $773598ba
773301D1 8DA42400000000   lea esp,[esp+$0000]
773301D8 8DA42400000000   lea esp,[esp+$0000]
773301DF 90               nop

'Call Stack' window IS EMPTY!

Pressing F8 three times, the program jumps to 

ntdll.RtlInitializeExceptionChain:
7735989F 8BFF             mov edi,edi

I cannot reproduce it on demand but I see the problem once per day (maybe less?).
The compiler/debugger is running in 32 bit.

Any idea if this is a debugger problem? I encountered something similar in the past: sometimes when you run an external application from your Delphi app, the debugger freezes. This is a documented bug for Delphi XE7. So, I am thinking, maybe this is a similar/related bug?

Gabriel
  • 20,797
  • 27
  • 159
  • 293
  • 1
    Here is a somehow similar problem but in my case the CPU is 0% and I cannot choose a thread: http://stackoverflow.com/questions/13057133/stopping-delphi-program-in-an-infinite-loop – Gabriel Feb 06 '17 at 11:37
  • 1
    Hard to say. Could very easily be a defect in your code. That's surely the most likely explanation. – David Heffernan Feb 06 '17 at 11:50
  • 1
    That's exactly what it has done. Smells like a deadlock due to a defect in your code. As a general rule, you should assume, until you find evidence to the contrary, that defects are in your code rather than the system. – David Heffernan Feb 06 '17 at 15:53
  • Wasn't the debugger supposed to stop in the current executing code when I hit 'Pause program'? It does this during a "normal" freeze, when the program enter a big FOR loop (100% CPU utilization) for example. And it shows the stack. So, why is this case special? Why the program freezes if there is no CPU utilization. I don't use threads (it is true that I have a TWebBrowser that could use threads). – Gabriel Feb 06 '17 at 15:54
  • "Smells like a deadlock" - in this case the debugger should pause in the thread that is waiting. – Gabriel Feb 06 '17 at 15:56
  • In a deadlock multiple threads are waiting. There is no single thread that is waiting. When you pause an executing process, it is arbitrary which thread is initially active in the debugger. Why do you believe your program is not defective? – David Heffernan Feb 06 '17 at 15:57
  • I don't believe anything. I am exploring possibilities. Plus that the compiler has also a REALISTIC chance of being flawed. We all know what happens with the 64 bit debugger. – Gabriel Feb 06 '17 at 18:22
  • 1
    Add madExcept and when the program freezes use madTraceProcess to pull out stack traces. Then look for your defect. – David Heffernan Feb 06 '17 at 18:24
  • Thanks David. I will do that. – Gabriel Feb 06 '17 at 18:26
  • I'm using `Delphi 10.0` and if I hit `Break` in the debugger there is **always** the wrong thread selected. I have to switch to another thread using the thread window until I find the right one. Luckily, on breakpoints the debugger does the right thing. Did you try to switch threads? You have to double-click the the thread number and sometimes you will find the correct stack trace. – ventiseis Feb 07 '17 at 13:42
  • Additionally check your project options. Of course, compiling without runtime packages, optimization and inlining improves debugging experience. Furthermore, enable debug information and stack frames. – ventiseis Feb 07 '17 at 13:44
  • @ventiseis-I have ALL these enabled (I used to use EurekaLog but it is way too buggy to be usable). This is why I can see the stack and execution point when I pause the program (when I WANT to pause it, not when it accidentally freezes). – Gabriel Feb 07 '17 at 14:26

1 Answers1

1

I am making progress here! I have found a similar issue in a program of mine. The freeze appears when I try to load a large text (over 100000) in a custom list box because of this code:

MyListBox.Items.Text:= xxx;


procedure TMyListBox.LBADDSTRING(var M: TMessage);   { This makes the control slow when I work with 100000 lines }
begin
 inherited;
 if Assigned(FOnChange)
 then FOnChange(Self, lbAdded);
end;

The execution point runs through LBADDSTRING for every line (100000 times). So, it seems frozen.

Odd is also the fact, that if I pause the program, Delphi cannot accurately show the execution point for my program (I checked all 5 threads). So, all this is in the end a Delphi debugger flaw.

Gabriel
  • 20,797
  • 27
  • 159
  • 293