2

I am working on a C# program that produces a very large piece of C code. It produces a .c file and accompanying header file. On a very basic level, the program accepts a string from the user, then compares it to thousands of other strings that have been placed in the header file during autogen.

The header file contains over 800k lines of code and the .c file contains around 300k. As you can imagine, these are very large files. Now, I realise that having such a large file is bad coding practice. The best thing would be to break this file down into smaller files and compile it that way, but can we assume that this two file structure is necessary for how my project will be used in the grand scheme of things.

With that in mind, I'm having trouble compiling this program in the Visual Studio IDE and with the command line. Infact, that's not entirely true. It appears to compile okay each time I try it with either method (admittedly it takes a while). However, when I come to run the program, problems develop. It reaches the input loop just fine, but after accepting user input, the program crashes with the following error:

"Unhandled exception at 0x008105f9 in Prototype.exe: 0xC0000005: Access violation writing location 0x00000000."

I'm fairly sure this is not my code causing the problem. I have run a version of this code generated in debug mode which is a lot smaller and it runs fine. The only difference is the volume of strings that have been written to the header file by the C# program. The size of the smaller files are 14k and 5k lines respectively. Also, the IDE does not allow me to use breakpoints to debug after compiling and running with the full sized code, whereas my smaller code does.

My question would be this: Is there any limit or issue that the C language or the Visual Studio compiler has with single large files that would be causing the error above? If so, is there any way to circumvent this limit while retaining my two-file structure? I have tried increasing heap and stack sizes to 4mb in the properties dialouge, but this does not help.

I realise that this is an abnormal way to produce and run code, but I would be appreciative of any advice.

Jack
  • 508
  • 1
  • 9
  • 18

1 Answers1

3

I realise that having such a large file is bad coding practice

No, it is not.

Having a file with LOGIC that is MANUALL MAINTAINED like that is bad practice.

Having a hugh file of constants is ARGUABLE,

but having a generated file like that does not show up on coding practices BECAUSE YOU DO NOT CODE IT. You generate it.

There are good points in having few files for generated code, such as ease of generation. VS.ENT does that iteself - EntityFramework etc. generate ONE cs file with tons of classes, all from one input model.

Is there any limit or issue that the C language or the Visual Studio compiler has with single arge files that would be causing the error above?

Nothing documented. You likely run into a bug few people ever see. I fear you are in for a rewrite OR - a PSS Support case (Microsoft Support Services), which likely is free if you found a compiler bug.

Alternatively it MAY be your code - if your debug cases are a lot smaller, it may be your code produces an error with the full data set, which IS more likely than a compiler issue.

I would suggest you make a debug run with the FULL files, not a small set. The debugger may point you to a surprising location.

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • 1
    "I would suggest you make a debug run with the FULL files, not a small set" - if that doesn't help, another thing I'd try is to allocate the same data structure dynamically, by reading in a plain text file containing the same strings as went into your autogen thing. Then run your code on the dynamically allocated structure. If it works on that but not on the header file of doom, that suggests it's the compiler that can't cope with that size of data, rather than your code. – Steve Jessop Jul 06 '12 at 10:45
  • Thanks for your suggestions. I will implement them and report back. – Jack Jul 06 '12 at 11:59
  • After testing your suggestions, it turns out I was barking up the wrong tree. I wasn't allocating enough memory to one of my structs and the program was filling it up too quickly. I've fixed the problem now. Thank you for your help. – Jack Jul 09 '12 at 09:29
  • 1
    ;) Talk barking up the wrong tree. Rule one - the compiler is correct. Rule two - rule one MAY SOMETIMES BE WRONG. 20 years programming, I have seen that ONCE (funny enough renaming (!) a variable fixed that). In general, it is safe to assume it is not a compiler issue ;) – TomTom Jul 09 '12 at 09:41