bug #17922 mem_malloc()

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

bug #17922 mem_malloc()

Christiaan Simons

Hi folks,

I've started to work on bug #17922, but I need some help from you folks.

If you have some spare time and want to fix this as much as I do,
please have a look at what I've just commited to mem.c rev 1.26

Please note this doesn't address possible alignment issues yet,
I want to save this after nailing the algorithm down.

Christiaan Simons

Hardware Designer
Axon Digital Design

http://www.axon.tv



This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: bug #17922 mem_malloc()

Jonathan Larmour
Christiaan Simons wrote:
> Hi folks,
>
> I've started to work on bug #17922, but I need some help from you folks.
>
> If you have some spare time and want to fix this as much as I do,
> please have a look at what I've just commited to mem.c rev 1.26

I've had a look. It looks fine from a reading. Also I don't think we should
handle near fits. Firstly, from the point of view of keeping it simple, and
secondly because I don't think you could sensibly handle them anyway since
you _always_ need to have an aligned struct mem following. A struct mem is
only three words after all.

> Please note this doesn't address possible alignment issues yet,
> I want to save this after nailing the algorithm down.

I don't think there are any in your changes, from my reading. ptr will be
aligned as long as it started off aligned. SIZEOF_STRUCT_MEM will be
appropriately aligned for the architecture, and size has been rounded up.

But I think there is a pre-existing problem - the ram array may only have
byte alignment, but mem_init assigns a (struct mem *) to its base which may
have stronger alignment constraints.

So in mem_init, it should actually be something like:
mem = (struct mem*)((ram + MEM_ALIGNMENT - 1) & ~(MEM_ALIGNMENT-1));


Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: bug #17922 mem_malloc()

Christiaan Simons
Hi Jonathan,

> I've had a look. It looks fine from a reading.

Sure? I'm not, cause TCP seems to fail after these changes.

> Also I don't think we should
> handle near fits. Firstly, from the point of view of keeping it simple,
and
> secondly because I don't think you could sensibly handle them anyway
since
> you _always_ need to have an aligned struct mem following. A struct mem
is
> only three words after all.

I don't agree. First of all, the case Tom supplied may pass now,
but with a slight mod it will fail again.

Let say we change the last mem_malloc(200) into mem_malloc(195),
and this fails again without good reason.
Just because we can't create a mem2 is a bad reason to fail here.

I do think I should round up the requested size to span
to the next properly aligned struct.

I'm not sure if I must do this for each mem_malloc() call
or if I need to perform this trick only for the last free block,
which does complicate things.

Maybe this also explains the odd TCP errors I get.

> But I think there is a pre-existing problem - the ram array may only have

> byte alignment, but mem_init assigns a (struct mem *) to its base which
may
> have stronger alignment constraints.

Agreed. I'll have a look at it.

Bye,

Christiaan.

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users