CoverStory doesn't output HTML on large datasets (over 1000 files)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. With either XCode 3.2.6 or XCode 4.2.1 turn on GCov results and build a 
large project with over 1000 files (I had 1233)
2. Confirm .gcno and .gcda files are produced during compile and execution 
respectively
3. Launch CoverStory 4.2.0 
4. Open folder location of .gcno and .gcda files (<build output 
dir>Objects-normal/x86_64/)
-> it will take 4-6 minutes or so with this many files but it does complete and 
you see the overall coverage number
5. File -> Export HTML
6. Choose a directory that you can write to (Desktop)

Expected: HTML files are written just like they are with smaller programs

Actual: CoverStory goes to 100% CPU for a second but not files written

What is the expected output? What do you see instead?
The command doesn't complete and no HTML is produced.

What version of the product are you using? On what operating system?
CoverStory 4.2.0 on Mac OS X 10.6.8 with XCode 3.2.6 (Mac Pro 5,1 with 16GB RAM)
and
CoverStory 4.2.0 on Mac OS X 10.7.3 with XCode 4.2.1 (Mac Pro 5,1 with 16GB RAM)

Please provide any additional information below.

The workaround is to look at individual files coverage but our project would 
like an easy way to export the whole coverage data set and archive that without 
having to just do screenshots to compare runs over time. Export to HTML works 
for smaller data sets.

Is there a way I can get the source and debug exactly where this is happening? 
What version of XCode did you use to build Coverstory 4.2.0? Are there build 
steps that I can try on my end?

Original issue reported on code.google.com by marimbas...@gmail.com on 14 Feb 2012 at 10:48

[GoogleCodeExporter]

Also found this in the Console:
2/14/12 4:45:05 
PM  [0x0-0x18e18e].com.google.CoverStory[84687] CoverStory(84687,0xa00f1540) 
malloc: *** mmap(size=1208320) failed (error code=12)
2/14/12 4:45:05 PM  [0x0-0x18e18e].com.google.CoverStory[84687] *** error: can't 
allocate region
2/14/12 4:45:05 PM  [0x0-0x18e18e].com.google.CoverStory[84687] *** set a 
breakpoint in malloc_error_break to debug
2/14/12 4:45:05 PM  CoverStory[84687]   Attempt to allocate 1208304 bytes for 
CFString failed

Original comment by marimbas...@gmail.com on 14 Feb 2012 at 11:19

[GoogleCodeExporter]

Code is available right here: 
http://code.google.com/p/coverstory/source/checkout

It builds cleanly on Xcode 4.2 (10.6.8)

I'd be interested to know what string is blowing out.

Original comment by dmaclach on 15 Feb 2012 at 5:31

[GoogleCodeExporter]

Hi Dave,

I tried to compile on Xcode 4.2.1 with 10.7.3 and I had to change to the 10.6 
SDK in the project settings. Even after I did that I still cannot get it to 
compile with error:
clang: error: no such file or directory: 
'/Volumes/Data/coverstory/coverstory-read-only/external/google-toolbox-for-mac/S
nowLeopardGcov/GTM_fdopen2003.c'

which is a file and directory that is not there and didn't come down with the 
SVN sync. I will try and dig into the google-toolbox-for-mac folders to try and 
find it next. Any other pointers appreciated.

Original comment by marimbas...@gmail.com on 21 Feb 2012 at 9:39

[GoogleCodeExporter]

I did a quick pass on fixing things up, so it should build now, but I didn't 
get a chance to really validate things.

Original comment by thoma...@gmail.com on 22 Feb 2012 at 12:20

[GoogleCodeExporter]

It now builds and runs correctly on XCode 4.2.1 and 10.7.3 - thanks for the 
updates.

In general I think I would like to request a 64-bit version of the app. I have 
16GB of RAM and on this many files I am pretty sure it is hitting the 32-bit 
memory ceiling for a single process. I am going to attach a number of things 
for you to help debug it and let me know if I can help further as I am very 
interested in this tool working for this project.

It goes into htmlSourceTabelData: and then I wrapped appledFormat: with this 
try catch block to see where the actual memory error is.

      @try {
    [sourceHtml appendFormat:
     @"<tr class='sourceline'>\n"
     @"<td class='sourcelinehitcount'>%@</td>\n"
     @"<td class='%@'>%@</td>\n"
     @"</tr>\n", hitCountString, hitStyle, lineSource];
      }
      @catch (NSException *e) {
          NSLog(@"ACK!");
          break;    // get out of the loop, returning what we can
      }

That isn't a fix, it is just to point out what happens when there is a memory 
error and no data gets written to the drive for any of the HTML files or 
folders.

Original comment by marimbas...@gmail.com on 27 Feb 2012 at 9:18

Attachments:

• CoverStory_Console_Stack_Trace.txt

[GoogleCodeExporter]

As far as I can tell you have a 64 bit version if you build it from sources. 
What does otool tell you?

Original comment by dmaclach on 27 Feb 2012 at 10:00

[GoogleCodeExporter]

Here is what I am doing (correct me if there is a different way to build 
CoverStory).
1) On Mac OS X 10.7.3, Sync latest code from CoverStory with "svn checkout 
http://coverstory.googlecode.com/svn/trunk/ coverstory-read-only"
2) Launch XCode 4.2.1
2) File -> Open -> ~/coverstory-read-only/CoverStory.xcodeproj
3) In the XCode GUI (screenshot attached) there is only a My Mac 32-bit option
4) Press Command -B to build.
I get a i386 folder with a 32-bit executable.

Compare that with HelloWorld an application I created with File-New-Project and 
I get the 64-bit option and a 64-bit executable. (see screenshot).

So I don't see a way to tell XCode to build the 64-bit app. Possible guesses:
a) Is there a scheme that didn't get checked into the project for 64-bit?
b) Should I be building CoverStory in some other way than the XCode GUI?
c) something else?

I also took a look at the xconfig files for CoverStory and Google Toolbox for 
Mac. I saw the iPhone targets but nothing for 64-bit there either.

Thanks again for checking on this.

Original comment by marimbas...@gmail.com on 28 Feb 2012 at 7:23

Attachments:

• CoverStory_My_Mac_32-bit_Only.png
• HelloWorld_64-bit.png

[GoogleCodeExporter]

Just pushed a new version of Coverstory (4.3) that should handle this.

A) Now 32/64 bit Intel (Dropped PowerPC)
B) we now use significantly less memory when exporting HTML

I think we are fixed. Let me know if this is not the case.

Original comment by dmaclach on 7 Mar 2012 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

The new 64-bit version works great. I can confirm it is now running as a 64-bit 
app in Activity Monitor and doesn't run out of RAM when I do an Export to HTML. 
Total RAM usage peaks at about 4.6 GB but then returns to 2.6GB after the 
Export to HTML is complete.

THANK YOU so much for this fix.  I will let you know if there is anything else 
but right now we are all set.

Original comment by marimbas...@gmail.com on 9 Mar 2012 at 6:59