×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

How to deal with stubborn "Dereference to null pointer" errors?

How to deal with stubborn "Dereference to null pointer" errors?

How to deal with stubborn "Dereference to null pointer" errors?

(OP)
When errors appear at random, say, when the identical procedure sequences of a program crash only sometimes, first we doubt about the reliability of the code. But as in this example, I can't imagine how a simple initialization fails sometimes. Like the one below. The image shows an example of the error under a code compiled in Labwindows/CVI environment.

_buffer = (double*)malloc(elementos*sizeof(double));

for (iii=0; iii< elementos; iii++)

_buffer[iii]=0.0;

On the first iteration (iii=0), Labwindows shows a "Dereference to null pointer" error message.

I've heard that in this cases is better to change the programming language to other that deals better with dereferences.

Please help!!

RE: How to deal with stubborn "Dereference to null pointer" errors?

>I've heard that in this cases is better to change the programming language to other that deals better with dereferences.
It sounds like after crash in the expression x/0.0 you want to switch to the programming language that deals better with divide by zero operations.

Better look at the malloc specification:

Quote (C Standard)

...If the space cannot be allocated, a null pointer is returned. If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

Now test if the value of elementos is too large, or negative, or is equal to zero. Good practice: always check out the pointer value returned by malloc (!= NULL). Regrettably, no such programming language that deals better with incorrect (too large, for example) memory requests.

Null pointer points to nowhere. It's not dereferencing error: it's memory allocation unsuccessful request.


RE: How to deal with stubborn "Dereference to null pointer" errors?

(OP)
Very good answer.

So, if elementos is well defined, should I just expect to use something like
[C]if (_buffer==NULL)
MessagePopup ("here I am", "try again"); [/C]

??

In that case, I'd repeat the whole procedure (reloading the file) until the error stops??

I tried a stupid thing before

[C]if( _buffer =(double*)malloc(elementos*sizeof(double)) ==NULL){

MessagePopup ("rr", "rr");
return;
}[(C]
(this is in a [C]void abrir (char rwfile[]) [/C] function

so that is why I'd really appreciate an explicit code for the good practice you mentioned.

many thanks again, this could really take many headaches away!!

RE: How to deal with stubborn "Dereference to null pointer" errors?

Well, it seems you understand the problem ;)
Your if (condition) is not stupid, it's incorrect expression example (see operator priorities in C). That's it in C language style (look at parenteses balance):

CODE

if ((_buffer = malloc(elementos*sizeof(double))) != NULL) { /* no need for cast if you have true C compiler */
    printf("*** Bad allocation, elementos == %d\n",elementos);
    ezit(1); /* or what else... */
}
/* let's continue... */ 

RE: How to deal with stubborn "Dereference to null pointer" errors?

Sorry, must be == NULL in my prev snipet ;(

RE: How to deal with stubborn "Dereference to null pointer" errors?

exit(1)... Probably, it's bedtime...

Good luck!

RE: How to deal with stubborn "Dereference to null pointer" errors?

(OP)
Thanks fot the code, It worked to check the pointer value returned by malloc, but after that, if repeating the function, memory never gets allocated. For some reason, when memory for _buffer is not allocated, the same happens to cleanbuffer. I thought that because this occurs sometimes, retrying it would solve the issue, but it seems not.

For what reason, other than the memory size (not being 0 nor too large), does malloc fail ??? I suspect this can be a complicated issue but really need help to solve this. It happens so little, and apparently at random, that is very annoying.

Portion of the relevant code

CODE -->

void abrir (char rwfile[])
{
	
	int iii;
	short buffer_abierto=0;		

	leidos = 0;	

	if (buffer_abierto)
		free (_buffer);
	
	GetFileSize (rwfile, &rwsize);	
	elementos = rwsize/sizeof(short);			

	buffer = (short*)malloc(elementos*sizeof(short));	
	cleanbuffer =(double*)malloc(elementos*sizeof(double));

	if(    ( _buffer=(double*)malloc(elementos*sizeof(double)) )  == NULL){
		
		printf("*** Bad allocation, elementos = %d\n",elementos);
		abrir(rwfile); //Here the function restarts, hopefully
	}
		
	buffer_abierto = 1;
	
	for (iii=0; iii< elementos; iii++){
		
		buffer[iii]=0;		
		cleanbuffer[iii]=0.0;  
		_buffer[iii]=0.0;  
	}
	
	fclose (bin_rw);
	
	for (iii=0; iii< elementos; iii++){
		
		if (buffer[iii]==NULL){		
	
		        if (iii==0)	
				buffer[0]=0;
			else			
				buffer[iii]=buffer[iii-1];
		}
			
		cleanbuffer [iii] = (double)buffer[iii] * BIT1V * (10000.00/(double)amplif)*f;	
	}
			
	free (buffer); 			
	
	
} 

Now I'll try with a while, hoping that at some moment malloc works fine.

Still unresolved but on its way, thanks to you.

RE: How to deal with stubborn "Dereference to null pointer" errors?

(OP)
Think I got It.

I just have too free memory (i.e. closing other running software) before calling the same function again.

My program is very non economical so 3 Gb of RAM is not enough sometimes. I'll have to do something with that. Not many time right now (I must USE the program not reprogram it right now), but at least I think I'm going in the right direction.


Thanks again!!thumbsup

RE: How to deal with stubborn "Dereference to null pointer" errors?

Dangerous code. You assign pointers to global variables, don't free (and never check) cleanbuffer allocation. You compare short buffer[iii] with pointer value NULL (why?). The last loop is exactly buffer and clearbuffer "assign zero to all elements" operation (think why - and look at the previous loop: it performs exactly the same work more clearly;).

Moreover: you are trying to call the function recursively but don't free possibly allocated buffer and clearbuffer - obviously, your program eats all accessible memory - it's a classic memory leak (and possible stack overflow) example. Recursive call don't stop previous call: it creates new stack frame and continues to eat memory...

If your program can't allocate dynamic memory chunk then chances to successful allocation without massive free operations (especially as recursive calls;) are equal to (short, int, long, float, double;) zero. Try to inform user then do exit...

RE: How to deal with stubborn "Dereference to null pointer" errors?

(OP)
That is why I am a tech user upsidedown.

Dind'nt understand all you said, but I dind't correct the code to ensure that there were problems (for example than cleanbuffer is never freed). The buffer==NULL comparation is remnant of previous intent of solving the issue.

Thanks I'll pass this to an expert to see it in person and to explain me the details of what you said.

RE: How to deal with stubborn "Dereference to null pointer" errors?

If it's possible, try to pass your problem(s) to the personal expert(s); don't waste a time on forums ;)

BTW, many years ago we solved 1-2-3GB data physical problems with 192K byte computer memory. Key words: proper algorithmes selection ;)

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close