Im debugging a C code...
Problems...
1) When using gdb, how do you get it to print the line at the seg fault/memory error. It crashes and using bt and where only shows the functions it occurred in?
Also...
2) the error occurs in strncpy/strcpy, how can this happen since they are from the standard headers?
1) If you compiled with -g, then you're in. You'll get something like (example taken from another poster's code):
2) If you pass something stupid to strcpy (like NULL), well then that's what you're going to get.Code:Program received signal SIGSEGV, Segmentation fault. 0x080486r1 in main () at graph.c:31 31 Graph[v-1][u-1] = 1;
so you have to compile with -g to get it? It doesn't just add it when using gdb? I use -Wall...
-g means "put the stuff gdb needs in the program file". Normally, the compiler isn't going to leave variable names and links to source code files and things like that in your finished program -- it's not necessary to the finished product and can take up some space. (That same example: 7400 bytes if compiling normally, 9908 bytes if compiled with -g.)
In regards to 2, that is so weird. As before that step I check the what is pass for NULL via:Originally Posted by tabstop
So.. Weird... IDKCode:char *ptr; ... ptr = strstr(string, wx_element); if(ptr != NULL){ strcpy(ptr_str, ptr) ... }
I guess you've got two chances there: ptr_str could be NULL, or it could point to non-writable memory. (F'rinstance, if you've done
then you're not going to be able to overwrite that.) But the obvious thing to do would be to recompile with -g and let it run and crash, and then print ptr_str and ptr and see what they are.Code:char *ptr_str = "bob";
IF it is non-writable memory, anyway to fix it? Get more memory in my heap (I use malloc() so it isn't my stack, correct?... or I believe).
Note, It's weird as I modified this function before and this never happend. As this error is occurring in another function call (I mean that this function calls a function within it where the strcpy error occurs). Wonder why it would show up now, having use GDB to fix the function that it happen to before.
is my results...Code:#0 0x881663f0 in strcpy () from /lib/libc.so.6 #1 0x00000000 in ?? () #2 0x08053734 in madis_wx_intensity (pres_weath=0x81163bb "-RA", ' ' <repeats 21 times>, auto_stn_type=0x813ddb2 " ", pass=1, precip1=0x2d, precip2=0x2d, precip3=0x2d, stn_type=0xbfbfe6a4, pcp_occurrence=0xbfbfe6a8) at sfc_oban.c:2623 #3 0x0805e049 in madis_data_density (w_lon=-130, s_lat=20, lon_res=0.0191204604, lat_res=0.0179639999, n_rows=1838, n_cols=3662, miss_val=-9999, sfc_time_window_hw=30, earth_rad=6370, sfc_data=0x808e000, an_params=0x8166000, sfc_climo=0x808f030) at sfc_stations.c:749 #4 0x0804c04a in main (argc=0, argv=0xbfbfea28) at ppaes_sfc.c:1648
I see this... pres_weath=0x81163bb "-RA", ' ' <repeats 21 times>,
What does that mean? Note, I try doing print ptr, or print ptr_string but it says No symbol "ptr" in current context.
Does #1 mean that a NULL was pass in? How can that happen since I check for it?
Last edited by towed; 12-28-2010 at 10:21 PM.
That just means it's been a bug the whole time, you just didn't manage to step on it before. If it's non-writable memory, you would probably have noticed long before now. You're going to actually have to do the debugging. If recompiling with -g isn't an option, that just makes it a little more difficult.
Hmm, well -g is an option at least.
0x000000 is a little weird to see in between there. You've got the line number where the strcpy called happened. The things in the parentheses should be the parameters that were passed in to the function. I.e., currently ppaes_sfc.c, at line 1648, called madis_data_density, and passed in -130, 20, 0.0, etc. At line 749 of that file you called madis_wx_intensity with some strings, 1, 45, 45, 45, etc. Then line 2623 happened.
Printing ptr won't work because currently you're in the middle of strcpy, and strcpy knows nothing of this ptr thing. I guess you didn't bother to get the debugging symbols for the library, which might be why you don't see arguments to strcpy. I have the feeling that that 0x0000000 is one of them, though.
You can type "up" to go up a stack frame (up through these things) until you get to your function, then start printing things.
You only checked one argument, not both.
Ok, I did that and got:
since im copying ptr_str into wx_second... its weird as I malloc for wx_second before using strlen(ptr_str)+1...Code:(gdb) up #1 0x00000000 in ?? () (gdb) up #2 0x08053734 in madis_wx_intensity (pres_weath=0x81163bb "-RA", ' ' <repeats 21 times>, auto_stn_type=0x813ddb2 " ", pass=1, precip1=0x2d, precip2=0x2d, precip3=0x2d, stn_type=0xbfbfe6a4, pcp_occurrence=0xbfbfe6a8) at sfc_oban.c:2623 2623 strcpy(wx_second, ptr_str); (gdb) print wx_second $12 = 0x0
What does the <n repeat> mean in the debugging output?
You should look at what is actually being called at line 2623. Is that a strcpy call, or is that a call to something else? You may have a library in between there. A test GDB run gave me for a backtrace
so that missing line probably represents code we can't see/don't have symbols for.Code:#0 strcpy (dest=0x0, src=0xbffff90f "Hello world!") at strcpy.c:40 #1 0x08048462 in main () at segfault.c:9
The repeats mean you have 21 spaces in your string.
And yes, something is going wrong with your malloc for wx_second. (OTOH, malloc can return NULL, if you are out of memory somehow.) (EDIT: For instance, you should check what strlen of ptr_str is -- if there's something "bad" about ptr_str, then you could have a weird number for strlen.)
