Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15100

Re: Memory leaking in memmove

Show all headers | View raw

On Wednesday, December 28, 2011 4:36:37 PM UTC+6, Philip Lantz wrote:
> ArifulHossain tuhin wrote:
> > My application is leaking memory in a memmove call. I have made it
> > sure from coredumps.
> I don't think you mean "leaking memory". That term specifically refers 
> to not freeing memory that was allocated. I'm guessing you mean that 
> your program is overwriting memory that it shouldn't.
> 
> > the offending code snippet reads as follows:
> > unsigned char pad_len;
> > pad_len = (unsigned char)((random() % RANSTOP ) + RANSTART);
> > if(pad_len%30 == 0)
> > pad_len = 9;
> > if(packet->size > 0){
> > 	memmove(packet->data.buf + pad_len, packet->data.buf, packet->size);
> > 	packet->size += pad_len;
> > 	packet->data.buf[0] = pad_len;
> > 	for(j=1; j< pad_len; j++)
> > 	packet->data.buf[j] = (char)256%j;
> > 	EnDeCrypt(packet->data.buf, packet->size, key, KEYLEN);
> > }
> > 
> > As the data.buf is statically allocated, valgrind does not complain
> > anything about it.
> > Is it running out of memory? or any other problem?
> > Any suggestion?
> 
> 
> There is no dynamic memory allocation in the fragment you have shown us, 
> so it can't be running out of memory.
> 

You are absolutely right. I guess i'm misinformed about terminologies. Thanks

> Are you sure that packet->size + pad_len < sizeof packet->data.buf? That 
> check should probably be in the code, unless there are constraints on 
> the packet size that guarantee that it is always true.

Packet size can be as high as 230 with pad_len. pad_len is unsigned char. so it should cover upto 256. sizeof(packet->data.buf) is 8 so it should not be a problem. Though i guess should put a checking into the code anyway.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Memory leaking in memmove ArifulHossain tuhin <etothepowerpi@gmail.com> - 2011-12-28 01:24 -0800
  Re: Memory leaking in memmove Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:20 -0800
    Re: Memory leaking in memmove ArifulHossain tuhin <etothepowerpi@gmail.com> - 2011-12-28 02:37 -0800
      Re: Memory leaking in memmove Philip Lantz <prl@canterey.us> - 2011-12-28 02:42 -0800
      Re: Memory leaking in memmove Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 03:36 -0800
        Re: Memory leaking in memmove ArifulHossain tuhin <etothepowerpi@gmail.com> - 2011-12-28 03:50 -0800
      Re: Memory leaking in memmove Seebs <usenet-nospam@seebs.net> - 2011-12-28 18:17 +0000
  Re: Memory leaking in memmove Philip Lantz <prl@canterey.us> - 2011-12-28 02:36 -0800
    Re: Memory leaking in memmove ArifulHossain tuhin <etothepowerpi@gmail.com> - 2011-12-28 03:57 -0800
      Re: Memory leaking in memmove Dr Nick <3-nospam@temporary-address.org.uk> - 2011-12-28 12:21 +0000
        Re: Memory leaking in memmove ArifulHossain tuhin <etothepowerpi@gmail.com> - 2011-12-28 04:26 -0800
      Re: Memory leaking in memmove jt@toerring.de (Jens Thoms Toerring) - 2011-12-28 12:46 +0000
  Re: Memory leaking in memmove ArifulHossain tuhin <etothepowerpi@gmail.com> - 2011-12-28 05:54 -0800
  Re: Memory leaking in memmove Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 14:46 +0000
    Re: Memory leaking in memmove Philip Lantz <prl@canterey.us> - 2011-12-28 12:20 -0800
      Re: Memory leaking in memmove Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 21:50 +0000
  Re: Memory leaking in memmove Barry Schwarz <schwarzb@dqel.com> - 2011-12-28 10:36 -0800

csiph-web