Doing 64bit app debugging with XE4 on Win 8.1
Doing 64bit app debugging with XE4 on Win 8.1
Application crashes with EInvalidGraphicOperation: Scan line index out of range and opens IDE with breakpoint on InvalidOperation proc.
After that IDE is totally dead, all I can do is kill it through TaskManager.
Has anyone seen something like that? Is this "normal" Delphi behavior or is it my code badly trashing something.
Application crashes with EInvalidGraphicOperation: Scan line index out of range and opens IDE with breakpoint on InvalidOperation proc.
After that IDE is totally dead, all I can do is kill it through TaskManager.
Has anyone seen something like that? Is this "normal" Delphi behavior or is it my code badly trashing something.
No 64 bit debugger is buggy as hell. Apart from your known remedy there isn't much you can actually do.
ReplyDeleteNever seen that message. Seems to indicate you are either in TDIBWriter.GetScanline or TDIBReader.GetScanline in Vcl.Imaging.GIFImg.pas Broken GIF?
ReplyDeleteTBitmap.GetScanLine is more likely. Broken bitmap?
Lars Fosdal No, my broken code working with bitmaps :)
ReplyDeleteProblem is that I cannot pinpoint exact location where my code breaks. In 32bit after the crash, with stepping through code I could get to my offending method, but now it just stops at Vcl.Graphics.InvalidOperation and freezes.
Ouch. No callstack even? Do you use MadExcept, EurekaLog or similar?
ReplyDeleteLars Fosdal Nope. Never had the need, until now :(
ReplyDeleteLife savers, for sure.
ReplyDeleteIs this in the main thread? Have you tried placing a breakpoint on the invalid operation call in GetScanLine?
Lars Fosdal Yep, no luck.
ReplyDeleteThen I'm with José - the debugger is wonky.
ReplyDeleteCompilable in 32-bit? Same problem there?
Lars Fosdal Found the error by reading code. It looks that going through 20000 lines of code is far easier solution than using debugger.
ReplyDeleteAfter that one, I also got another exception (simple to locate this time), but it only confirms that after raising any kind of exception in code IDE freezes and I cannot do a thing.
On the bright side, I have been rarely using debugger anyway. With all the unit tests in place I hardly ever need it at all.
Unit tests are life savers too :)
ReplyDeleteCan't say I've had that problem in the 32-bit debugger - but that one is not entirely stable either. It sometimes peels off into "code I never wrote" and dies - especially when debugging threads.
Lars Fosdal 32bit works, but it uses asm methods I have been translating to Pascal.
ReplyDeleteThing is I have started this job back when XE2 was released and I have just finished it yesterday. There was a lot of code and before I was completely done I could not really test it without spending significant amount of time creating tests. It is graphic library and that makes testing more difficult. And of course, error was not in recently written code.
That is exaclty the kind of situation where I use a console :D
ReplyDelete{$IFDEF LOG}
AllocConsole;
WriteLn('so far, so good');
{$ENDIF}
Paul TOTH How do you free it?
ReplyDeletePaul TOTH Good one :)
ReplyDeletePaul TOTH - I use a modified OutputDebugString. I recently added a 4k line circular buffer that allows me to dump the buffer to a logfile after a problem occurred, and then continue logging to file. Sending the EurekaLog exception stacks to this mechanism saves a lot of work where you would be trying to recreate a situation where there are hundreds of variables involved. Working with live data is like juggling dynamite ;)
ReplyDeleteYour debugger is in a different process. Your code should not be able to kill the debugger. x64 debugger sucks.
ReplyDeleteJosé RamÃrez I don't, it's only for debug purpose, the first call to AllocConsole open a console window where all the WriteLn ouputs goes, nothing special to do for that.
ReplyDeletePaul TOTH This is trace debugging. It's a very useful tool, and one that is not widely known amongst modern day programmers. Who grew up with interactive debuggers.
ReplyDeleteDavid Heffernan or simply for multithreaded code, where even the best debugger often struggles. Or is pointless "when two threads interact like X, breakpoint both threads and then ???". I have a remote server that runs on very different hardware in PROD and TEST, so debugging generally means "turn on 1MB/s of logging and hope the problem still occurs". Untangling log files with 10+ active threads is a fun job all by itself.
ReplyDelete+Moz Threaded code should not make debuggers crash. No excuse for that. The fact that breaking into threaded code changes its behaviour just means that trace debugging is often a more useful tool.
ReplyDeleteNot uncommon. The 64-bit debugger is very unstable.
ReplyDelete