|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| gcampton (859) | |||
|
I'm having occasional errors when testing my program, I'm not quite sure. When this error occurs creates stackdump then will continue to produce the same error until I delete the stackdump. only thing I could find on stackdump was: http://www.cplusplus.com/forum/general/4282/ which was completely useless. What is a stackdump? Unfortunately the error didn't point to any specific line being it was exec, which is usually what I read when looking at errors it said something about char * std:: alloc etc.. I didn't quite get it .... hit the enter key too soon and ended up back in VI, and unfortunately being that I was using VI opening shell, when I quit to go check the error again it had scrolled off the term. I have tried to reproduce the error but it is not comming up at the moment, I assume I will get it again sooner or later I hope so i can try and figure out what is going on. There is only 1 if statement that it seemed to happen on a few times. This is my code:
The bottom if or possibly the creating of StringSort object most likely causes, I don't think it would be the object because at the moment all it is taking iparam and oparam as constructor args and setting them, with a couple cout test statements in constructor, setters, and runApp... I'll post back if I come across the error again, I just don't want to submit this knowing the code may be flawed, something I may be overlooking... Thanks for reading so far. | |||
|
Last edited on
|
|||
| gcampton (859) | |
|
ok got it again i tried this on another computer using cygwin I commented out the include header and lines 70,71 compiled fine then I ran the exe as: ./a -i iinnnn -o ouuttttttt 16 [main] a 3704 _cygtls::handle_exceptions: Error while dumping state<probably corrupted stack> segmentation fault (core dumped) | |
|
|
|
| writetonsharma (1181) | |
|
debug the core using gdb and you will know where you got the exception. if its a release binary, compile it with -g option and you can debug the core. syntax: gdb binary_name core try it. | |
|
|
|
| gcampton (859) | |||||
|
ok I have never used this before but gave it a shot, running the exe with args ::
now compile using -ggdb flag now that's useful :D thanks a bunch, so now that gdb has confirmed that what I thought was correct, can I say now change this to if *argc>=5 and retest etc, and it should tell me if successful yea?
Also in the manual it doesn't talk much about debugging symbols, is there a better resource to look up how to use debugging symbols in code? | |||||
|
Last edited on
|
|||||
| gcampton (859) | |
|
I'm wondering why was the comparison against 0 throwing this seg fault? I'm pretty sure i tried comparing to != NULL but it told me that it had to be an int which is why I changed to 0... doesn't matter too much anyway argc>5 is essentially the same. | |
|
|
|
| helios (9408) | |
| You're doing it wrong. You're not supposed to check argv[i][0]. If you do that, the [0] dereferences the pointer and you get a segmentation fault when i==argc. You're supposed to check argv[i]. | |
|
|
|
| gcampton (859) | |
line 29: while ((row<argc)&&(argv[row][0]=='-')) is also going to cause this error?I did read up on pointers before this, but assumed from what I read you can still treat them much like arrays, but I'm not quite sure what you mean.... are you saying that comparing [i][j] to 0 will be comparing against memory address? | |
|
Last edited on
|
|
| firedraco (4744) | |
| If you are accessing element [i][j] of an array, it means you are still dereferencing the 2nd pointer (to get the j-th element), but if that pointer is NULL, then you can't deference it. | |
|
|
|
| gcampton (859) | |
| ah ok thanks. | |
|
|
|
| helios (9408) | |
| Shit, I forgot to click the submit button. Oh, well. | |
|
|
|