Is my code too large?

[TinyMage]

 One of my code files is extremely large ( like 4000 lines or so ) and I have been having bugs when I compile it with code blocks.

 When I ran it it would crash even before getting to the part where the code from the file came into play.

 Then I checked "optimize code for speed" in the compiler options and it ran fine.

 Then I added a few more lines to the large file, and when I ran it it crashed again.

 Then I checked "optimize fully for speed" and it ran fine again.

 All of this was done with stable code that had ran fine previously.

 Theoretically could this be an issue with the large size of that particular file?

[Ceniza]

It shouldn't be a problem at all. 4000 lines may be long for a single file, but there are projects where such files exist, even longer, without causing any problems. You say your program crashes with some flags, yet it works if you change them. It can be caused by a faulty compiler (I guess you're using a good one and a stable version, so it shouldn't be it), or it can be caused by faulty code that may fail/work under some rare circumstances. Debugging that code is not easy, but, believe me, chances are it's really something in your code.

Now that I think of, there's another common situation: linking against non-updated object files or libraries. Does that file depend on some other kind of binary file? If so, please be sure to recompile everything and try again.

Another thing you may want to try is to debug a crashing binary. Just be sure to compile it with debugging symbols (-g) and _WITHOUT_ stripping (_WITHOUT_ -s), and run it through the debugger.

If nothing of that helps, at least give us more information about your environment: Operating System, Code::Blocks version, Compiler and version, ...

[TinyMage]

Hmm, running it through the debugger works

When I put only the -g flag and compile and run it through the build command it crashes at the same spot through, LOL.

I am using SDL and it says SDL Segmentation Fault - which means a memory error ( usually ).

Operating system = Windows XP

Code Blocks version = 8.02

Compiler = GNU GCC Compiler ( the default that came with codeblocks ).

The thing is this particular piece of code that is crashing worked for months.... :shock:

Maybe I should switch compilers or something?

[Jenna]

Or you really have a memory error.
I just had similar problems on my laptop, and when testing memory with memtest86+ and laptops diagnostic-tools both found exactly one bit that always stays one.

[TinyMage]

Or you really have a memory error.
I just had similar problems on my laptop, and when testing memory with memtest86+ and laptops diagnostic-tools both found exactly one bit that always stays one.

Hmm, I have no idea what you said there.

What do you mean one bit always stayed one?

[Jenna]

That means when writing a logical zero in this bit it still reads as a logical one.

That sometimes leaded sometimes to segfaults (when started a program from console), sometimes gcc believed it had an internal compiler error, and sometimes applications crashed silently (when started from graphical filemanager or menu).

I had a similar error years ago on an old 486-box. That leads to not being possible to install w2k because of errors when trying to copy the installation files on hdd.

If you run with or without debugger the program most likely uses different parts of the memory.

I don't say you have a hardwre error, but you should make sure it is not.

I didn't believe it on my laptop, because really memory errors are very rare. Nevertheless I have to work with 1 GB instead of 4 GB (until I get the new memory) and when compiling two instances of C::B at the time, workflow becomes really slow.

[Jenna]

By the way the "main.cpp" of C::B has more then 4000 lines of code and it compiles without problems and it can be run through gdb without crashes.