trident-job / delphi-code-coverage

Automatically exported from code.google.com/p/delphi-code-coverage
0 stars 0 forks source link

Win64 running with -u or -uf switch leads to Access Violation #62

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Unzip attached CodeCovTest.zip project
2. Adjust Build_all.bat lines 6+7: Delphi_XE2/XE6_Setup
   variables to the actual Delphi XE2 and XE6 install 
   paths on your system. Save and close Build_All.bat.
3. CodeCoverage.exe binaries v1.0 RC10 for Win32 and Win64 
   are included in the \x32 and \x64 folders, respectively
4. Run Build_All.bat from a command prompt
5. Windows Crash report raised for CodeCovTest_XE2.exe
   (Exception code: c0000005 etc).
6. Build Script stops at step 2b. [Running CodeCoverage 64-bit
   for the XE2/Win64 build of CodeCovTest_XE2.dproj
7. The Delphi-Code-Coverage-Debug.log (see zip) file shows:

Adding coverage:UnitWithCode.pas (UnitWithCode) 21
Clearing BreakPoint at 00423550
De-Activate UnitWithCode.pas line 21 BreakPoint at:00423550
ACCESS VIOLATION at Address:00423556
C0000005 not a debug BreakPoint

What is the expected output? What do you see instead?
> would expect entire script to run flawlessly

What version of the product are you using? On what operating system?
CodeCoverage version 1.0 RC10, for Win32 and Win64

Please provide any additional information below.

1) If you remove the -u switch ("-u UnitWithCode") from the 64-bit invocations, 
there is no crash. But then you miss the unit level coverage output.

2) Also using the -uf switch instead causes the same problem.
This is only for Win64.

3) The same happens for XE6 Win64 projects. Remove the XE2 builds from 
Build_All bat to check for XE6 in Build_All.bat.

4) Perhaps I'm missing some required Delphi project level setting[s]?
(-> release mode, but enabling Debug information, Local Symbols and Detailed 
Map file).

Original issue reported on code.google.com by kristo...@xs4all.nl on 26 Nov 2014 at 4:18

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by e.kotlya...@gmail.com on 28 Nov 2014 at 8:22

GoogleCodeExporter commented 9 years ago
Have you had a chance to look at this yet? 
Any idea whether it's really hairy or simple to fix?

Original comment by kristo...@xs4all.nl on 14 Jan 2015 at 12:31

GoogleCodeExporter commented 9 years ago
Sorry for the delay. Unfortunately I'm not able to reproduce this issue on my 
machine. Difference I see in the log file is that number of external modules 
loaded is different. Currently in 64-bit mode external loaded DLLs are not 
shown correctly, so I need to fix this to see what is the difference and what 
module causes the exception.
Could you tell what OS version you use? And could you try to run it as 
administrator, this maybe related to some permissions.

Original comment by e.kotlya...@gmail.com on 14 Jan 2015 at 6:02

GoogleCodeExporter commented 9 years ago
Well that's annoying! I tried running the test on a different system (Windows 7 
SP1, 64-bit edition; Dell Vostro laptop), and found here there is no crash!

On my Development machine, however, a 64-bit test exe will crash while running 
under DelphiCodeCoverage every time:
OS: Windows Vista Ultimate (64-bit) SP2, Build 6002 [English (United Kingdom)]
HW: CPU: Intel(R) Core(TM) i7 CPU 920 @2.67GHz, 8 cores, 6134MB RAM

My command prompt always runs in elevated / Administrator mode. I don't see any 
option to obtain even more privilege.

I will check tomorrow how this goes on our company Build Server, it hadn't 
occurred to me yet that the issue might be specific to one machine.

thanks & best regards,

Kristofer

Original comment by kristo...@xs4all.nl on 14 Jan 2015 at 11:48

GoogleCodeExporter commented 9 years ago
I've been able to do some more testing. It looks like this behaviour is 
specific to Windows Vista. One of my colleagues has an almost identical 
development machine, also Windows Vista Ultimate x64, SP2. His is the only 
other machine in my surroundings where this problem can also be reproduced. My 
other colleagues as well as the BuildServer use Windows 7 or later, here there 
seems to be no problem.

So I suggest we put this issue to rest, no use worrying about compatibility 
with such an old OS, although of course it would be nicer if it wasn't a 
problem. And to save future grief, perhaps you should add a note of this on the 
Wiki page. 

I'll just have to figure out a way to detect Vista in my build scripts, and 
conditionally skip the 64-bit coverage tests in such cases.

Kristofer

Original comment by kristo...@xs4all.nl on 15 Jan 2015 at 12:31

GoogleCodeExporter commented 9 years ago
Thanks for investigating it, I'll add note to the wiki.

Original comment by e.kotlya...@gmail.com on 16 Jan 2015 at 6:55