C program compiled with cygwin in Windows works, segmentation fault under Linux. Is cygwin GCC 'bad'?

Question

For my Programming 102 class we are asked to deliver C code that compiles and runs under Linux. I don\'t have enough spare space on my hard drive to install Linux alongside Wind

Answer 1

The version of GCC is probably not the issue. It's more likely to be a difference in the runtime library and a bug in your code that doesn't manifest itself when running against the Windows version of the runtime. You might want to post the code that segfaults and some more background information if you want a more specific answer.

In general, it's best to develop under the environment you're going to use for running your code.

Answer 2

I don't mean to sound rude, but it's probably your code that's bad, not the compiler. ;) Problems like this are actually more common than you'd think, because different OS's and compilers will have different ways of organizing your application's data in the stack and heap. The former can be particularly problematic, especially if you end up overwriting memory on the stack, or referencing freed memory which the system has decided to use for something else. So basically, you might get away with it sometimes, but other times your app will choke and die. Either way, if it segfaults, it's because you tried to reference memory which you were not allowed, so it's more of a "happy coincidence" that it didn't crash under another system/compiler.

But really, a segfault is a segfault, so you should instead debug your code looking for memory corruption instead of tweaking the compiler's configuration to figure out what's going wrong.

Edit: Ok, I see what you mean now... I thought you were coming at this problem with an "X sucks, but Y works just fine!" attitude, but it seems to be your TA who's got that. ;)

Anyways, here's some more hints for debugging problems like this:

• Look for pointer arithmetic, referencing/dereferencing for possible "doh!" errors. Any place where you are adding/subtracting one (aka, fencepost errors) are particularly suspect.
• Comment out calls to malloc/free around the problem area, and any associated areas where those pointers are used. If the code stops crashing, then you're headed in the right direction.
• Assuming you've at least identified the general area where your code is crashing, insert early return statements in there and find the point where your code doesn't crash. This can help to find an area somewhere between that point and where your code actually crashes. Remember, a segfault like this may not necessarily happen directly at the line of code where your bug is.
• Use the memory debugging tools available on your system.
  • On Unix, check out this guide for debugging memory on unix, and the valgrind profiler (@Sol, thx for reminding me about this one)
  • On Visual Studio/Windows, your good 'ol buddy CrtCheckMemory() comes in rather handy. Also, read up on the CRT memory debugging patterns, as they're one of the nicer features of working in VS. Often times, just leaving open a memory tab in VS is enough to diagnose bugs like this once you memorize the various patterns.
  • In Mac OSX, you can set a breakpoint on malloc_error_break (either from gdb or Xcode), which causes it the debugger to break whenever malloc detects memory corruption. I'm not sure whether that's available in other unix flavors, but a quick google search seems to indicate it's mac-only. Also, a rather "experimental" looking version of valgrind seems to exist for OSX.

Answer 3

You definitely have a bug somewhere in your code. It's possible that the Windows memory manager is being more lax than the Linux memory manager. On Windows, you might be doing bad things with memory (like overwriting array bounds, memory leaks, double-free'ing, etc.), but it's letting you get away with it. A famous story related to this can be found at http://www.joelonsoftware.com/articles/APIWar.html (search for "SimCity" on that (somewhat lengthy) article).

Answer 4

Are you making any platform-specific assumptions, like the size of data types, data structure alignment in structs, or endianness?

Answer 5

It's almost certainly a pointer error or buffer overrun, maybe an uninitialised variable.

An uninitialised pointer will usually point at nothing, but sometimes it will point at something; reading from it or writing to it will typically crash the program, but then again it MIGHT not.

Writing or reading from freed memory is the same story; you might get away with it, then again maybe not.

These situations depend on exactly how the stack, heap are laid out and what the runtime is doing. It is quite possible to make a bad program that works on one compiler / runtime combination and not another, simply because on one it overwrites something that doesn't matter (so much), or that an uninitialised variable "happens" to contain a valid value for the context it's used in.