Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Memory leaking in memmove (http://www.velocityreviews.com/forums/t807441-memory-leaking-in-memmove.html)

ArifulHossain tuhin 12-28-2011 09:24 AM

Memory leaking in memmove
 
My application is leaking memory in a memmove call. I have made it sure from coredumps.

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);
}

the packet data structure is decalared as follows:

struct rtp_packet {
size_t size;
................
(some fields)
................
struct rtp_packet *next;
struct rtp_packet *prev;
union {
rtp_hdr_t header;
unsigned char buf[8192];
} data;
};

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?

Nick Keighley 12-28-2011 10:20 AM

Re: Memory leaking in memmove
 
On Dec 28, 9:24*am, ArifulHossain tuhin <etothepowe...@gmail.com>
wrote:
> My application is leaking memory in a memmove call. I have made it sure from coredumps.
>
> 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);
>
> }
>
> the packet data structure is decalared as follows:
>
> struct rtp_packet {
> * * size_t * * *size;
> * * ................
> * * (some fields)
> * * ................
> * * struct rtp_packet *next;
> * * struct rtp_packet *prev;
> * * union {
> * * * * rtp_hdr_t * * * header;
> * * * * unsigned char * buf[8192];
> * * } data;
>
> };
>
> As the data.buf is statically allocated, valgrind does not complain anything about it.
> Is it running out of memory?


well? is it? How do you know you have memory leak?

> or any other problem?
> Any suggestion?


I can't really see how this leaks. Where does packet come from?

Philip Lantz 12-28-2011 10:36 AM

Re: Memory leaking in memmove
 
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.

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.


ArifulHossain tuhin 12-28-2011 10:37 AM

Re: Memory leaking in memmove
 
The app crashes with seg fault. Coredump's backtrace shows it occurs in memove() statements.

The packet comes from network, its a RTP packet embedded in UDP payload.

Philip Lantz 12-28-2011 10:42 AM

Re: Memory leaking in memmove
 
ArifulHossain tuhin wrote:
>
> The app crashes with seg fault. Coredump's backtrace shows it occurs
> in memove() statements.
>
> The packet comes from network, its a RTP packet embedded in UDP payload.


packet->size must be out of range. You should check that it is a valid
value. Perhaps it was -1, indicating an error, which was converted to
size_t, yielding a very large number.

Nick Keighley 12-28-2011 11:36 AM

Re: Memory leaking in memmove
 
On Dec 28, 10:37*am, ArifulHossain tuhin <etothepowe...@gmail.com>
wrote:

> The app crashes with seg fault. Coredump's backtrace shows it occurs in memove() statements.


that doesn't sound like a memory leak to me. Print (or use a debugger)
the values of the parameters passed to the memmove(). In fact why not
just use a debugger? A debugger can also be used on a core dump.

> The packet comes from network, its a RTP packet embedded in UDP payload.


I meant, how was it allocated.

ArifulHossain tuhin 12-28-2011 11:50 AM

Re: Memory leaking in memmove
 
On Wednesday, December 28, 2011 5:36:59 PM UTC+6, Nick Keighley wrote:
> On Dec 28, 10:37*am, ArifulHossain tuhin <etothe...@gmail.com>
> wrote:
>
> > The app crashes with seg fault. Coredump's backtrace shows it occurs inmemove() statements.

>
> that doesn't sound like a memory leak to me.


Sorry for the mistake. Actually its "SegFaulting".
> Print (or use a debugger)
> the values of the parameters passed to the memmove(). In fact why not
> just use a debugger? A debugger can also be used on a core dump.
>


I have used gdb to print the parameters passed to memove(). But i'm unsure what to do with it. Any suggestion ? what should i do with the parameters?

> > The packet comes from network, its a RTP packet embedded in UDP payload..

>
> I meant, how was it allocated.


rtp_packet is allocated dynamically. But the data.buf field is allocated asyou see as static allocation.

ArifulHossain tuhin 12-28-2011 11:57 AM

Re: Memory leaking in memmove
 
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.

Dr Nick 12-28-2011 12:21 PM

Re: Memory leaking in memmove
 
ArifulHossain tuhin <etothepowerpi@gmail.com> writes:

> 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.


How long is your actual packet buffer? - you say above that it's 8 but
you might be misunderstanding the question. If not, then you'll have
problems.

If at any time packet_size + pad_len is longer than the size of
packet->data.buf then you'll be scribbling on memory you don't own.

Can you show us the code that defines and sets packet->data.buf

As packet->data.buf must contain at least as many bytes as the maximum
length of pad_len, can you tell us what RANSTOP and RANSTART are
#define'd to?

It might be worth printing pad_len just before the memmove and seeing
what the value is when it blows up.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

ArifulHossain tuhin 12-28-2011 12:26 PM

Re: Memory leaking in memmove
 
On Wednesday, December 28, 2011 6:21:03 PM UTC+6, Dr Nick wrote:
> ArifulHossain tuhin <etothe...@gmail.com> writes:
>
> > 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.

>
> How long is your actual packet buffer? - you say above that it's 8 but
> you might be misunderstanding the question. If not, then you'll have
> problems.
>

Its given in the original post.Below the code snippet, the structure definition of packet is given there. Its about 8192 bytes long. more than enough to hold multiple copies. I was talking about the data type of packet->data.buf which unsigned char.

> If at any time packet_size + pad_len is longer than the size of
> packet->data.buf then you'll be scribbling on memory you don't own.
>
> Can you show us the code that defines and sets packet->data.buf
>
> As packet->data.buf must contain at least as many bytes as the maximum
> length of pad_len, can you tell us what RANSTOP and RANSTART are
> #define'd to?
>


3 and 9

> It might be worth printing pad_len just before the memmove and seeing
> what the value is when it blows up.
> --
> Online waterways route planner | http://canalplan.eu
> Plan trips, see photos, check facilities | http://canalplan.org.uk




All times are GMT. The time now is 09:54 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.