resource manager eating memory

QNX DEVELOPERS Realtime and Embedded
1

Hi there,

I have followed a pretty straight forward text book example on writing a resource manager. For some reason my write function is eating memory. The only thing I really added was extending the attribute structure.

[code]
int channel_write(resmgr_context_t *ctp, io_write_t *msg, iofunc_ocb_t *ocb){
int status;
uint8_t * buffer;
int nbytes;
uint16_t seglen;
int Channel;
int opt;
int offset;
datalink_struct * dev;

dev = ocb->attr->dev;
Channel = ocb->attr->Channel;
offset = sizeof(msg->i);

/*Tests*/
if ((status = iofunc_write_verify(ctp, msg, ocb, NULL)) != EOK){
	return (status);
}
if ((msg->i.xtype & _IO_XTYPE_MASK) != _IO_XTYPE_NONE){
	return(ENOSYS);
}
nbytes = msg->i.nbytes;
if(nbytes){
	ocb->attr->attr.flags |= IOFUNC_ATTR_MTIME | IOFUNC_ATTR_DIRTY_TIME;
}
opt = 500;
if (opt > nbytes){
	seglen = nbytes;
}
else{
	seglen = opt;
}
if ((buffer = (uint8_t *) malloc((size_t)(seglen+8)*(size_t)sizeof(uint8_t))) == NULL){ //+8 for the headers and CRC
	return(ENOMEM);
}
memset((void *)buffer,(char) 0x00,(size_t) (seglen+8));
if (resmgr_msgread(ctp,buffer+6, seglen, offset) ==-1){ //This is where the data begins
	free(buffer);
	return(errno);
}

//my functions()
free(buffer); // test for now
buffer = NULL;

_IO_SET_WRITE_NBYTES(ctp,seglen);
ocb->attr->attr.flags |= IOFUNC_ATTR_MTIME | IOFUNC_ATTR_DIRTY_TIME;
ocb->offset += seglen;
return (EOK);

}[/code]

Regards,
Christian

2

Is it growing without bounds, or does it grow to a certain size and then stabilize?

3

Every time I write to the device it grows. It is stable until the next write.

4

Don’t see anything obvious. What if you remove the malloc?

seglen should be a 32 bit value.

The calculation for the size in the malloc and memset should be the same. Right now it it doesn’t cause a problem because sizeof (uint8_t) is equal 1.

5

Even with the everything from malloc to free commented out, the program grows from 4100 to 4196 after the first write to the device. So some “under the hood” function is allocating some memory that I don’t know of.
Could it have something to do with the attr struct, which I have redefined?

6

After the first write, I would expect that. Is it consuming memory at every write()?

I don’t see how redefining the attributes structures would affect this. Do you dynamically create attributes or is it static.

7

Yes that is after every write. I do a “cat test.file > /dev/ch1”, Every time the cat operation completes the resource manager is sitting on more memory.
Would it help if I attached the whole .c resource manager file. It may be that I did something wrong somewhere else?

8

Yes and if it can compile/link that would be best.

9

Ok, I have created a stripped down version of the code, that works, but contains the problem.
Once compiled try “cat any.file > /dev/ch1”, while keeping tabs on the size with ps.
Thanks alot for checking into this. I have been sitting on this problem for quite a while.

10

That goes to show when checking for a bug complete source code should be submitted :wink: The bug is not in the writer handler, it`s in the thread.

while(1){
	ctp = dispatch_context_alloc(dpp);
	if((ctp = dispatch_block(ctp)) == NULL){
		//printf(stderr, " block error\n");
		return EXIT_FAILURE;
	}
	dispatch_handler(ctp);
}

Ill let you find it, that way youll never make that same mistake again. That works for me :wink:

I compiled your code with gcc 3.3.5, I assume you are using 2.9.5 because 3.3.5 wasnt happy about it. Im surprised it compiled with 2.9.5, there are thing like const variables being modified.

I can offer some suggestion to improve the code. If this is the type of thing you are interested in just mention it and I`ll take some time to comment it.

11

Thanks yes, I think I see that I don’t deallocate the ctp. I introduced a dispatch_context_free( ctp ) and the problem is solved. Thanks.
Yes I would appreciate comments.

12

No the problem is that you allocated the context in the while loop. It should be done only once. Comments about the code later today.

13

File attached, check for my comments starting with //—

14

Hi Mario,

I appreciate your time and experience.Thank you for your help and for your comments.

Kind regards,
Christian