Thank you all for your help have managed to find the problem and at least the app starts to load and give reasonable feed back
Tracked it down with breaks on the initialisation sections and found a file pulling in the non Unicode version of gnugettext. After I renamed the path so the complier/ linker couldn’t find it we started to progress Thanks again all Ian Fear From: [email protected] [mailto:[email protected]] On Behalf Of Jolyon Direnko-Smith Sent: Wednesday, April 12, 2017 7:24 AM To: NZ Borland Developers Group - Delphi List <[email protected]> Subject: Re: [DUG] How to find Access Violation in the Initilization of Project There's no such thing as a "$C0000005 access violation" as such. What you have is an access violation with the $C0000005 address involved. That address could be the location in memory of the instruction at which the AV occurred, or it could be the address of the memory than an instruction attempted to access. The difference is important and can help identify the problem but it's difficult to say which address this represents from the way you describe it. A typical AV exception will read something like "Access violation at $AAAAAAAA attempting to read/write/access address $MMMMMMMM". $AAAAAAAA is rarely of any use, although if you are very lucky you can use it with "Goto address" in the IDE to take you to the line of source code corresponding to that address. To do that the debug build in the IDE has to be IDENTICAL to the build in which the AV occurs, and the build needs to be running, but "paused" under the IDE. If the build isn't identical then the source code you find at that address is unlikely to be the actual instruction at which the AV occurred, and even if the buid is identical it isn't always reliable (though I've never quite figured out why). The value of $MMMMMMMM is usually more useful and can be a first indicator of what's going wrong. e.g. if the problem is a NIL object reference or pointer than $MMMMMMMM will be $00000000 (nil). If it is an extremeley low value such as $00000004 or $00000012 etc, then this too indicates a nil pointer or object reference, where the actual memory access is at some offset from the nil pointer. e.g. a property or member variable reference using a nil object or an array access using a nil pointer. The lower the value, the more likely it is to be a member variable reference. If $MMMMMMMM is anything significantly greater than nil then this usually indicates an uninitialized pointer or an access to an already destroyed object. Other than that, if the problem is occurring during initialization then you need to find all your initialization sections and debug those. But this will be harder if the problem is in an RTL or VCL unit. You will need to compile with Use Debug DCU's enabled, but if you do that and can reproduce the AV under the debugger then all you should need to do is run the build under the debugger. Make sure that "Break on exceptions" is enabled in the debugger and also that EAccessViolation is not on the "ignore" list in the debugger options. Hope that helps. On 10 April 2017 at 10:09, Todd Martin <[email protected] <mailto:[email protected]> > wrote: Hi Ian Search through all the files in your project and look for the initialization keyword. Put a break point wherever you find code. Then run the application and see where it dies. On 10 Apr 2017 6:56 a.m., "Ian Fear" <[email protected] <mailto:[email protected]> > wrote: I am in the process of Moving a Project from D2007 to D XE10 berlin. After some grief I have the Project Compiling in XE10. When the project loads I Get a $C0000005 access violation in the Projects Initialization section before I get to any breakpoints on main form Create etc On following it thru the CPU window it Happens at vcl.AxCtls or 4 lines later Tpicture.loadFileFormats Would appreciate any hints on how to track this down. It May be trying to call in a FMX unit but cant figure out how to track it Down Any Hints or suggestions greatly appreciated Thanks in advance Regards Ian Ian Fear B Agr Sc (Lincoln) GDip InfSys(Massey) Fear Consulting Ltd 405 Old Taupo Road Rotorua Home /work 07 347 6015 Mobile 027 474 2772 _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] <mailto:[email protected]> Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] <mailto:[email protected]> with Subject: unsubscribe _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] <mailto:[email protected]> Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] <mailto:[email protected]> with Subject: unsubscribe
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
