buglwIP - A Lightweight TCP/IP stack - Bugs: bug #29375, Error in memp_malloc with CVS Head...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #29375: Error in memp_malloc with CVS Head Revision

Submitter:  EisenkolbThomas <poweruser>
Submitted:  Tue 30 Mar 2010 05:56:48 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  Crash Error Status:  Works For Me
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Jump to the original submission

Wed 21 Apr 2010 08:03:31 PM UTC, comment #10: 

Closing as this really isn't a bug. We could add a debug-check for freeing in correct pool and double-freeing, though.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 02 Apr 2010 10:40:21 AM UTC, comment #9: 


> Is there any case where the tries to place zero pointer Messages in a mbox?


Yes, a zero pointer in the recvmbox for TCP netconns means "connection closed by remote side".

Simon Goldschmidt <goldsimon>
Group administrator
Fri 02 Apr 2010 08:41:41 AM UTC, comment #8: 

Okay I have now changed the driver to avoid any operation with a zero pointer in the mailbox and now it is working.

But I have to take a look about it.
Is there any case where the tries to place zero pointer Messages in a mbox?

EisenkolbThomas <poweruser>
Thu 01 Apr 2010 08:46:24 AM UTC, comment #7: 


> Is it possible to use two different netconns each from another thread?


Yes, that's possible.

> The "result" variable in the sys_mbox_trypost method is initialized


Yeah, sorry, seems like my quick look was too quick :-)

Other than that, I have no clue what's going wrong for you. Maybe you should add a check to memp_free that an item is not already freed (or freed twice). I would add that to CVS, too, but I it might take some days until I find the time to do so.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Apr 2010 08:22:54 AM UTC, comment #6: 

Okay in my comment there was a little mistake.
Is it possible to use two different netconns each from another thread?
SO what I mean I don't use "one" netconn from two threads.
Is it thread safe to do so?

If not, which kind of connection can I use from different threads to stay thread safe.


In the driver file there are a few things I have to explain.
 All the things that look like I don't check array sizes is beacuse of I don't need to check because in each array the last element contains a zero element. So an Out of Array Error is not possible in most of the methods.
The only thing tha is missing is a zero pointer check.
I already changed this.

The "result" variable in the sys_mbox_trypost method is initialized because if os_mbx_send returns != OS_R_OK, there is still the else condition where the variable is initialized to ERR_MEM. So this is no error and the result variable is initialized in any way before the method returns.

EisenkolbThomas <poweruser>
Thu 01 Apr 2010 07:20:09 AM UTC, comment #5: 

Using one netconn from more than one thread at a time is not supported (yet?), so that could well be your problem.

However, after having a quick look at the file you posted, there are many places where you don't ceck array indices, so you might well overwrite somethin in memory which doesn't belong to the array. This could lead to a hard fault, too...

And there is a bug in sys_mbox_trypost(), although I'm curious why your compiler doesn't complain about this: if os_mbx_send returns != OS_R_OK, result is uninitialized. And if it is zero before, the function will return ERR_OK and there you go with what I said in comment #1.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Apr 2010 06:23:54 AM UTC, comment #4: 

I checked the sys_mbox_trypost and I am sure that everthing is alright with the method.

I give you the source code of my os driver. Maybe you can take a look at it.
I am using RTX from Keil and for this reason you have to allocate the mboxes and semaphores before you call sys_mbox_new.
I think you will understand the mechanism I use in the file to provide this.

I always get the hard fault, so it is very difficult to get the exact position where the error occurs.

May I have only a problem with the netconn's. May I use the netconn connections from 2 different threads or could this result in an Error?

EisenkolbThomas <poweruser>
Wed 31 Mar 2010 02:18:25 PM UTC, comment #3: 


> Is it possible to include a mechanism, that freeing an item 2
> times doesn't matter?


No way. I can imagine adding (debug-only) code to assert at the point when the item is (invalidly) freed a second time, but just letting the 2nd free pass would be a bug itself!

Could you try to check what's really going wrong instead of making the code live with the error? Have you had a look at sys_mbox_trypost or what I wrote in comment #1?

Simon Goldschmidt <goldsimon>
Group administrator
Wed 31 Mar 2010 11:29:17 AM UTC, comment #2: 

Okay I have now tried a few things with the mem_free and the memp_free.

At first there in the mem_free there is no security in the case of a zero pointer in void *rmem.
Maybe you can include ther same as in memp_free.
In my Opinion this is very important because in the case of a zero pointer, the pointer is decremented to nonzero and after that the memp_free identifies a bad pointer.

In the next step, I tried to free an item twice.
I am sure I am not the only one who does a mistake in the freeing of memory.
If you do it twice beacuse of any reason, not the memory pool where the item was allocated will be decremented and freed but the memory pool at the index before will be decremented.
As I have found this is the reason for my 0xffff or 0xfffb in the stats of the pools.

So if you allocate 3 pools of the following sizes.
 - 3 x 200 byte
 - 3 x 600 byte
 - 3 x 1500 byte

If you know free an item of the 1500 buffer two times, at the second time not the item in the 1500 buffer but the 600 buffer is modified.

I fyou than allocate an item from the 600 buffer, there can happen anything and this is the reason why my controller gets a hard fault.

Is it possible to include a mechanism, that freeing an item 2 times doesn't matter?

Thanks a lot and I hope my description is helpful.

EisenkolbThomas <poweruser>
Tue 30 Mar 2010 06:59:29 AM UTC, comment #1: 

Although there is currently no (debug-) code checking if an item to free is not freed twice, looking at the code, your description strongly suggests there is a problem with your mbox implementation: TCPIP_MSG_INPKT elements are only allocated in tcpip_input() and freed in tcpip_input() (when sys_mbox_trypost() returns != ERR_OK) and tcpip_thread() (after the message has been processed).

The code in tcpip_thread leaves virtually no chance to free a message twice, but you should make sure that your sys_mbox_trypost() implementation either enqueues the message passed and returns ERR_OK or does not enqueue the message and returns an error. Otherwise the message might be freed both by tcpip_input() and tcpip_thread() when sys_mbox_trypost() enqueues the message but returns != ERR_OK.

I don't think this is a bug in lwIP, however, I'll leave this open as "works for me" until you checked that.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 30 Mar 2010 05:56:48 AM UTC, original submission:  

Hello,

I have a very interesting problem with the alloc and free functions in the memp.c.

After a few hour I always get a Hard Fault on the Luminary LM3S9B96 in the fundtion where the stack tries to allocate memory for the MEMP_TCPIP_MSG_INPKT.

Now i watched the lwip_stats structure and in the memory region for this type of memory there is the max value at 0xFFFF and the used value at 0xFFFB.

Is there a Bug when freeing the memory.

It looks like there is more memory freed than allocated.

Thanks for your help.

Regards, Thomas

EisenkolbThomas <poweruser>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #20083:  ETH_RTOS_Driver.c added by poweruser (6KiB - text/x-csrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by poweruser (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-21 goldsimon Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2010-04-01 poweruser Attached File- Added ETH_RTOS_Driver.c, #20083
    2010-03-30 goldsimon StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code