int i = 0;  
    char *ptr[1];  
    ptr[0] = RT_NULL;  
    while(1)
    {
        ptr[0] = rt_malloc(64);  
        if (ptr[0] != RT_NULL)  
        {  
            rt_kprintf("%d: 0x%x", ++i, ptr[0]);           
            rt_free(ptr[0]);   
        }
    }

后来我把rt_malloc()里的分配chunk的代码变为首先先判断z->z_freechunk是否为空，如果是空，就按照基地址+z_uindex*size的方式分配chunk，否则就将z->z_freechunk分配给chunk，然后再把z->z_freechunk->c_next付给z->z_freechunk。这样如果是完整的一对分配和释放就会使得每次新分配的chunk地址不递增。
这样的分配OK不？

这个和你的应用有关系。但是，如果使用RT的内存管理，不加入lwIP的补丁，在TCP反复连接，断开会很容易造成内存耗光

TCP的传输我们现在还没有发现内存溢出的问题，我现在遇到的问题是关于UDP发送的。
udp_sendto_if()中的“q = pbuf_alloc(PBUF_IP, UDP_HLEN, PBUF_RAM)”分配了一块内存，然后调用ip_output_if()继续向底层走，然后发送成功后返回到udp_sendto_if()继续走，然后调用“pbuf_free(q)”回收之前分配的内存。问题就出在这里，这个q并没有被回收，当要进行下一个数据包的发送时，再次调用pbuf_alloc()时这个q的地址是以64Byte递增的。这个问题如何解决呢？
我用的是RTT的内存管理。

我在slab.c中看slab分配时，发现每一个UDP发送，它申请的z_uindex就自加一，所以导致分配的chunk的地址就每次向上递增，但是z_nfree在每次分配的时候是和z_nmax相等，而且z_freechunk就是上一个数据包回收的chunk地址。这个z_uindex难道不应该是回收后就自减的吗？

你的 LWIP 用的是它自己的内存管理还是 RTT 的？

我用的是RTT的自己的内存管理。

#define MEM_LIBC_MALLOC             1
#define mem_malloc                  rt_malloc
#define mem_free                      rt_free
#define mem_calloc                    rt_calloc

嗯，CCS 的可以根据 R4 的 libcpu 来移植，除了 cpsid 之类的指令在 ARM9 上没有，需要改写下意外，应该式一样的～

而且 R4 的汇编部分优化过，应该会比 ARM9 的效率高些～

是cortext-r4??

嗯，CCS 的可以根据 R4 的 libcpu 来移植，除了 cpsid 之类的指令在 ARM9 上没有，需要改写下意外，应该式一样的～

而且 R4 的汇编部分优化过，应该会比 ARM9 的效率高些～

什么是R4？哪个芯片？