ansaurus

Question

Access violation while the program was idle - not trace information to track down the bug

Answer 1

A:

That's what EurekaLog does when it has nothing to work with. You need to rebuild and have the linker produce a detailed map file. That's how it knows what to apply its stack trace to.

Mason Wheeler 2010-10-17 14:42:04

Hi Mason. The map file is generated. It was generated since ever and I never disable that setting. This is why Eureka CAN catch other errors. This report is the only one that looks strange. I think it cannot catch the error because the program was not actually running through any of its branches. It was just idle.

Altar 2010-10-17 14:58:54

Answer 2

A:

I just wonder what's on line 76[16] in Amper.exe... That line number might be a hint of the location of the error.
Then again, when it's just happening during an idle moment then it basically happens when the system is processing Windows messages like the mouse moving, keyboard events, timer updates and a lot more.
It sometimes helps to search for the error message plus code. I've done a quick scan and found this KB from MS which suggests that this kind of error can happen when you call certain Windows API's with invalid parameters. But this KB doesn't apply to your error. Still, it gives you an idea about what to check: any Windows API call you make in your own code.
Does it also generate this exception in the IDE, while you're debugging?

Workshop Alex 2010-10-18 09:46:33

1) Line 76 is "Application.Run" which means... well... the whole program. 2) "what to check: any Windows API call you make in your own code" - small correction: I should probably check any Windows API call executed when the program is idle. This will restrict the search area a bit. 3) No. Only at runtime.

Altar 2010-10-18 12:50:12

Well, could have guessed it would be the Application.Run part. :-) It's not the whole application, though. Just the parts that are active at that moment. Any forms you have open, components on those forms, threads that are running in the background and -considering the error- very likely some Windows messages and API calls that are used incorrectly. (Although even the Delphi source code might have this kind of flaws.)

Workshop Alex 2010-10-18 13:56:26

And you might not like it, but have you tried to compile your application with a different Delphi version? Not sure if you have another version available but it could be that some error in the Delphi source code itself has been fixed in a newer version...

Workshop Alex 2010-10-18 13:57:49

@Alex - I only license I have is for Delphi 7. I guess I could use the trial version of Delphi 2010 or so. | The application was idle. None of my code was running (maybe except custom paining for some components, though I don't see why components need to be painted while the application is not visible). So, it must have been something in the IDLE loop. How do I see what kind of code is executed while the application is idle?

Altar 2010-10-19 10:10:53

That trial version might at least indicate if it's a problem in your code or the D78 runtime. About those custom painting controls. It's not likely that the painting gets executed, but you might want to check the calls you make in those methods. About checking which code gets called, I generally create a global text file variable and let critical procedures write lines to it. It's not ideal but helps checking for runtime errors without the debugger.

Workshop Alex 2010-10-19 12:24:55

Answer 3

+2 A:

I don't see an EditWndProc() method in user32.dll, but Delphi has a couple -- one dealing with combobox messages and one dealing with tree views. Given MS's comctrl mess, I'd guess you have a tree view?

Check your tree view stuff. Given IntersectClipRect's parameters, it's easy to guess that it's being passed an invalid device context -- so...are you doing any custom painting for your tree view? If so, are you checking to make sure the canvas handle is ! NIL before you begin painting (try assertions if nothing else)?

Erik Knowles 2010-10-18 17:03:34

Hi Erik. Thanks for your answer. I do not have any TTreeView, TShellTreeView or so. But I have a TFileList and TDirectoryList if this counts. I have no custom painting in these controls. I have quite several other controls in which I do custom painting but unfortunately they are scattered across many many forms. It is damn difficult to find the error when I don't even know which form generated it :(

Altar 2010-10-19 10:00:37

Yep, those do count. My guess is that they're getting dynamically updated to reflect changes in a particular file folder. Stop thinking about an "idle loop" -- you're dealing with a regular Windows message that's not being processed correctly. Look carefully at the event handlers you have attached to these controls; if necessary, comment out all the code and see if things go OK.

Erik Knowles 2010-10-19 15:20:35

Oh, and IIRC, TCanvas can definitely wind up with NIL handles in cases where Windows doesn't want you painting stuff (i.e., GetDC() returns 0). Trying to use that handle will bork stuff.

Erik Knowles 2010-10-19 15:21:40

ansaurus

tags:

views:

answers:

Access violation while the program was idle - not trace information to track down the bug

related questions