Thread: gdb/C question

Originally Posted by tabstop

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

Code:

#0  strcpy (dest=0x0, src=0xbffff90f "Hello world!") at strcpy.c:40
#1  0x08048462 in main () at segfault.c:9

so that missing line probably represents code we can't see/don't have symbols for.

2623 is the strcpy()...

Sorry, I don't what you mean by "missing line".

Originally Posted by towed

2623 is the strcpy()...

Sorry, I don't what you mean by "missing line".

As you can probably tell by the timestamps, this got posted as you were posting your other reply. So it was another attempt to see what was going on with your 0x000000 line. But since we know line 2623 is strcpy, we don't have to worry about it.

Code:

(gdb) down
#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 ptr_str
$1 = 0x88087ff0 "-RA"
(gdb) print wx_second
$2 = 0x0

This suggest to me since I can see what ptr_str is, that its strlen would be 3... so don't see nothing wrong with that...

Any more ideas? I am adding a malloc/error returns NULL statement to see what happens...

Testing for the error message w/

Code:

                    wx_second = malloc(strlen(ptr_str) + 1);

                    if(wx_second == NULL){
                       printf("** Error in madis_wx_intensity. **\n");
                       printf("** Unable to allocate space for wx_second char pointer. **\n");
                       printf("** Halting execution with error code 2b. **\n\n");
                       return 2;
                    }

it now prints...

Code:

** Error in madis_wx_intensity. **
** Unable to allocate space for wx_second char pointer. **
** Halting execution with error code 2b. **


Program received signal SIGSEGV, Segmentation fault.
madis_wx_intensity (pres_weath=0x81163d4 ' ' <repeats 24 times>, auto_stn_type=0x813ddb8 "     ", pass=1, precip1=0x0, precip2=0x0, precip3=0x0, 
    stn_type=0xbfbfe6a4, pcp_occurrence=0xbfbfe6a8) at sfc_oban.c:2187
2187       strcpy(string, " ");

So malloc returned NULL... And it now it fails on the next strcpy call that follows after another malloc ( im assuming that one fails.) ...

Once you're out of memory, you're really out of memory -- only thing left is to shut it down.

The next thing to look at is: how much memory are you using anyway? Are you freeing any of these calls to malloc when you are done with the data? Are you ever done with the data? How much data do you have running around when this happens?

gdb has no way of looking for memory leaks. For that, maybe you could look at valgrind or another similar tool. I'm not completely sure how well it works in this situation, but if you do an exit() when malloc gives up instead of going on to let the next malloc kill you, then you should get a report about any unfreed blocks that are still hanging around.

(EDIT: The other way you can get NULL from malloc is to pass it 0 for the size, but it seems fairly clear that at least in this instance that isn't happening.)

Originally Posted by tabstop

gdb has no way of looking for memory leaks. For that, maybe you could look at valgrind or another similar tool. I'm not completely sure how well it works in this situation, but if you do an exit() when malloc gives up instead of going on to let the next malloc kill you, then you should get a report about any unfreed blocks that are still hanging around.

(EDIT: The other way you can get NULL from malloc is to pass it 0 for the size, but it seems fairly clear that at least in this instance that isn't happening.)

Yeah, I have it print strlen() when it fails and it returned 3. So, I THINK it is safe to say its memory leak or not enough being present. Could it be that conclusive (in regard to the diagnoses).

Originally Posted by towed

Could it be that conclusive (in regard to the diagnoses).

It is conclusive that malloc is an out-of-memory situation. Whether it's a memory leak or you just requiring more than you have I can't say.

Well the aforementioned freeing seems like it worked, given that it now has passed that point in the program. Thanks tabstop ... I think I learned a thing or two with this discussion.

(EDIT: The other way you can get NULL from malloc is to pass it 0 for the size, but it seems fairly clear that at least in this instance that isn't happening.)

strlen(ptr_str)+1 can become 0. but I guess it's just because of memory leak.
@OP you can use valgrind to find out leaks.

How can strlen(ptr_str)+1 become 0. Doesn't strlen have to be positive?