another SEGFAULT

Hi,

I found another segfault in my app with gdb:

Code:

Program received signal SIGSEGV, Segmentation fault. 0x0804cb3e in main (argc=1, argv=0xbfc71904) at main.c:978 978 _check_prg = _check_node->data; (gdb)

I then made a

Code:

(gdb) inspect _check_node->data Cannot access memory at address 0xda1

which is kinda weird as the code looks like

Code:

while (_check_node != NULL) { _check_prg = _check_node->data;

and _check_node was allocated like:
head = (node_t *) malloc(sizeof(node_t)); (it is of type node_t*)
This is from code that's not written by myself but now how can I verify that _check_node->data is accessible without running into a seg fault?
Would if (_check_node->data) do it? I think that would throw a seg fault too, when it tries to access that memory block, no?

Thanks,
Ron

What does

Code:

head = (node_t *) malloc(sizeof(node_t));

have to do with _check_node ??

And generally, no. The debugger you are using is the best method to check this. Never rely on code for checking unallocated data, because programs not always throw SEGFAULTs. In other words, be glad when you get a SEGFAULT :)

Hmm, it seems really odd that it would be written as a loop like that. But anyway, it looks like _check_node has been assigned an invalid address at some point. Check the point of initialization, and after the malloc to see if you can spot something suspicious. Barring that, you've probably got an even more serious problem (eg: buffer overflow overwriting the pointer).

It might be a good idea to post more code...

Okay, yay,
good morning... :) let's look at that again today. So gdb tells me:

Quote:

Program received signal SIGSEGV, Segmentation fault.
0x0804cb3e in main (argc=1, argv=0xbfcec494) at main.c:978
978 _check_prg = _check_node->data;
(gdb)

And the code around those line looks like:

Code:

if (head->next) { _check_node = head->next; pthread_mutex_lock(&prg_mtx); while (_check_node != NULL) { _check_prg = _check_node->data; if (_check_prg != NULL){ if (check_point > (_check_prg->prg_bus.bus_timestamp + 120)) {

And I assume that _check_node at a certain point isn't NULL but referes to an invalid address.
I see that head after declaration in the header never gets set to NULL before this code snippet but it gets malloc-ed like this:

Code:

head = (node_t *) malloc(sizeof(node_t)); if (!head) return PRS_MEMORY_FAILURE;

Where node_t is declared like:

Code:

typedef struct node_t { void *data; struct node_t *next; struct node_t *prev; } node_t;

I'm not sure how i can prevent this, any suggestions would be appreciated!
Thanks!
--
Ron

Quote:

Originally Posted by cerr

And I assume that _check_node at a certain point isn't NULL but referes to an invalid address.

_check_node could have a valid address, but if _check_node.data has not been assigned anything it could contain a garbage address.

Quote:

Originally Posted by MK27

_check_node could have a valid address, but if _check_node.data has not been assigned anything it could contain a garbage address.

Well the actual malloc code looks like:

Code:

head = (node_t *) malloc(sizeof(node_t)); if (!head) return PRS_MEMORY_FAILURE; /*set the node to initial values */ head->prev = NULL; head->next = NULL; head->data = NULL;

Sorry for not pasting everything...

Without a COMPLETE example which you can post that demonstrates a crash, you're asking us to take part in a crap-shoot.

For a seg-fault
- you didn't initialise it
- you didn't allocate it
- you messed around with the pointer (like walked it off the end of an array)
- you freed it, then tried to access it
- you messed up the malloc size calculation to begin with
- you didn't prototype malloc to begin with
- you returned a pointer to a local variable
All these, and many more, are ways you could have screwed up.

Quote:

Originally Posted by Salem

Without a COMPLETE example which you can post that demonstrates a crash, you're asking us to take part in a crap-shoot.

For a seg-fault
- you didn't initialise it
- you didn't allocate it
- you messed around with the pointer (like walked it off the end of an array)
- you freed it, then tried to access it
- you messed up the malloc size calculation to begin with
- you didn't prototype malloc to begin with
- you returned a pointer to a local variable
All these, and many more, are ways you could have screwed up.

Okay, I will have to look into this more. The problem is, this code isnt' from me and i hoped that there would be some kind of mechanism to react upon a seg fault like the try/catch() statements in Windows, however I realized that there's nothing quite similar in Linux so I guess it's up to me to research what's causing this segfault... which I agree is the clean solution but time is pressing me, that's a problem.... :( well... i'll do my best...

Quote:

Originally Posted by cerr

Okay, I will have to look into this more. The problem is, this code isnt' from me and i hoped that there would be some kind of mechanism to react upon a seg fault like the try/catch() statements in Windows

I think you are referring to some other (interpreted) language, not C, with the try/catch bit*. Features like that are more or less impossible with purely compiled languages (such as C). This does not really have to do with the OS.

I also think this is a threading issue. How much programming with pthreads have you done? If the answer is "none", then you are simply in over your head. The sad truth is, that can happen to everyone. I cannot simply pick up any piece of code at all and do anything I want with it -- no one can.

And if you are in over your head, there is not really anything you can do except to admit it and move on to something else, maybe something which will help you learn what you need to understand (it's about pthreads, and you need some more basic programming experience ;) ). No point in banging your head against the wall.

Quote:

which I agree is the clean solution but time is pressing me, that's a problem

It's not just "the clean solution" it is THE ONLY SOLUTION.

* javascript and I think java have this, some other languages have eval() -- but they all rely on an interpreter of some sort.