Picture This

Oct 09, 2006 03:34

My days work. Coding from 12 pm to 3 am, with a break for dinner, showering and about 2 hours at my neighbors. Picture my entire days work that i have been trying to figure out comes down to one very last compile of the night. it works...then i try it with a different set of data. What happens. A FUCKING SEGMENTATION FAULT!!!!*screams on top of ( Read more... )

programming

Leave a comment

tuxmentat October 9 2006, 14:35:02 UTC
This is why I hate C :P I would triple check for bounds on arrays first..

Do you use an IDE with a debugger? Sometimes it helps to set some stop points in the code and let it run through the debugger to see where it fucks up. You might be able to narrow it down to a single method or block of code.

BTW, have you heard about lint. Many unix systems have it installed by default (I just checked and pegassus/freddie has it). If you don't have it you can probably get it via yum, or perhaps use splint.

Reply

zewrestler October 9 2006, 14:45:13 UTC
i've been using xemacs for this project. and compiling it in a sun machine.

Reply

tuxmentat October 9 2006, 14:57:37 UTC
Hehe, you are doing it old school! :)

Well, you can always try to use gdb. It's not the most user friendly app though... :/

Reply

zewrestler October 9 2006, 15:04:29 UTC
which do you think will be better?

Reply

tuxmentat October 9 2006, 15:31:07 UTC
Do you mean xemacs vs IDE?

As awesome as emacs is, I think IDE's make coding easier, especially on complex projects. It seems that Eclipse can be configured for C++. If that sun machine has Java installed you can probably install up Ecl in your home directory :). I never really used it for C but with Java you can literally stop the program at any point and examine any variable in a nice GUI explorer thing.

You may also check out:

Bloodshed Dev-C++ (windows only)
Kdevelp (linux only)
Code Blocks (multiplatform)

Most of these should have built in debugger tools.

If you are asking gdb vs lint - then I would say use both.

Lint will examine your code, and point our potential bug-prone segments. It's a little bit like a stricter compiler run that will catch issues with bounds, shaky pointer arithmetic and etc...

Gdb will let you to step through the program and examine the stack. I think you can set breakpoints inside gdb by doing breakpoint filename.c:function_name. You run it with run and continue from a breakpoint with c or step. ( ... )

Reply


Leave a comment

Up