z1: malloc doesn't work when running z1 mote on Cooja

[Jiffkuo]

I found an issue about malloc, if you use malloc in C code and compile the code within z1 board then running it on Cooja simulator. No error report after the compilation. However, malloc always returns NULL.

After investigation, I think we can modify msp430-main.c:141 as below,

 if (incr > (unsigned int)(stack_pointer - cur_break)) {
  ...
 }

Could you help to review the modification? Does it make sense?
Thank you

Tzu-Chi

[OlegHahm]

First of all: are you sure you want to use malloc() on embedded device - particular a really constrained one such as the MSP430?

Second: I'm not really sure I understand your proposed solution. Have you verified that it fixes your problem? Can you elaborate why casting the result to unsigned int should make a difference?

[Jiffkuo]

Hi,

Thanks for your prompt reply.

1. Yes, I agree with you. It's better to use static instead of dynamic
   memory allocation on embedded device. Right now, I am doing an experiment
   about memory performance and management, so I need to use malloc to
   allocate some space dynamic. Of course I do monitor the size of malloc in
   my code.
2. Yes, I did verify it. The reason is I found if the value of cur_break is
   greater than the value stack_pointer, which means "stack_pointer -
   cur_break" generates negative result (e.g. 0x fdfe), it makes 'if (size >
   (stack_pointer - cur_break))' statement always false.
   I think it's good to ensure no overlapping on stack_pointer, but we
   should calculate memory address with unsigned or absolute value. So that's
   why I cast 'unsigned int' with the statement. It's my 2 cents.

Thanks.

Best regards,
Tzu-Chi

2016-11-21 6:31 GMT-08:00 Oleg Hahm notifications@github.com:

First of all: are you sure you want to use malloc() on embedded device -
particular a really constrained one such as the MSP430?

Second: I'm not really sure I understand your proposed solution. Have you
verified that it fixes your problem? Can you elaborate why casting the
result to unsigned int should make a difference?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#6150 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AWhB1eMzR4ykskz_NXlCvGo0edNnnwLJks5rAas3gaJpZM4K3eC2
.

[Jiffkuo]

By the way, I realized that 'unsigned int' may be not good solution for all
cases (e.g. address starts with 0xfxxx_xxxx). The point is that we should
get the absolute offset value during the address calculation.

2016-11-21 10:54 GMT-08:00 Jiff Kuo jiffkuo@gmail.com:

Hi,

Thanks for your prompt reply.

1. Yes, I agree with you. It's better to use static instead of dynamic
   memory allocation on embedded device. Right now, I am doing an experiment
   about memory performance and management, so I need to use malloc to
   allocate some space dynamic. Of course I do monitor the size of malloc in
   my code.
2. Yes, I did verify it. The reason is I found if the value of cur_break
   is greater than the value stack_pointer, which means "stack_pointer -
   cur_break" generates negative result (e.g. 0x fdfe), it makes 'if (size >
   (stack_pointer - cur_break))' statement always false.
   I think it's good to ensure no overlapping on stack_pointer, but we
   should calculate memory address with unsigned or absolute value. So that's
   why I cast 'unsigned int' with the statement. It's my 2 cents.

Thanks.

Best regards,
Tzu-Chi

2016-11-21 6:31 GMT-08:00 Oleg Hahm notifications@github.com:

First of all: are you sure you want to use malloc() on embedded device -
particular a really constrained one such as the MSP430?

Second: I'm not really sure I understand your proposed solution. Have you
verified that it fixes your problem? Can you elaborate why casting the
result to unsigned int should make a difference?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#6150 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AWhB1eMzR4ykskz_NXlCvGo0edNnnwLJks5rAas3gaJpZM4K3eC2
.

[PeterKietzmann]

@Jiffkuo I didn't follow your description above in detail but however, cooja was never (really) part of RIOT ( #1921 wasn't merged). Also, there was no conversation since one year. You think we can close this one?

[Jiffkuo]

Yes, please close it. Thanks From Jiff Kuo iPhone

…

Peter Kietzmann ***@***.***> 於 2017年11月27日 09:25 寫道： @Jiffkuo I didn't follow your description above in detail but however, cooja was never (really) part of RIOT ( #1921 wasn't merged). Also, there was no conversation since one year. You think we can close this one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jabberimaher]

hi,
please how integrate cooja in riot os?
thank you