POSIX mq_receive NULL Priority

[Joel Sherrill]

On 3/18/2013 10:34 AM, Vincent Galbo wrote:
>
> Hello,
>
> I am not sure if this bug is common knowledge or not, but I figured I 
> would report my findings.
>
I don't know it can be called common  knowledge because I didn't
even remember it. :) The logs mention PR 1890 and PR 1895.

But I committed the fix on 2011-08-21 to the head

http://git.rtems.org/rtems/commit/cpukit/posix/src/mqueuerecvsupp.c?id=e5ca6593f7c7b543481147ca7f87696ecc821c06

And to the 4.10 branch on 2011-09-01

http://git.rtems.org/rtems/commit/cpukit/posix/src/mqueuerecvsupp.c?h=4.10&id=a1bfb335c0cc274513e144da46e203bff29e000b

Is there a newer Gaisler version? cc'ing Daniel Hellstrom for feedback.

And thank you for reporting this again. This time we got an easy solution.

> I am working with RTEMS-4.10-1.2.7 on a UT699 LEON3. I received my 
> RTEMS source from http://www.gaisler.com/anonftp/rcc/src/ .
>
> I have been using the function mq_receive to pass messages between 
> POSIX threads (http://linux.die.net/man/3/mq_receive). Many manual 
> pages explain that the fourth parameter, *msg_prio, can be left NULL 
> if you do not care about the message priority. During some testing, I 
> noticed that my mkprom2 boot loader was becoming corrupted. I 
> determined that the mq_receive call was overriding my memory location 
> 0. This was due to passing NULL into the priority parameter value. The 
> mq_receive function must not check for NULL, and places the priority 
> of the received message into whatever memory location is placed in the 
> msg_prio parameter. My current work around is to pass in a dummy 
> variable for the priority parameter.
>
> Vincent Galbo
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130318/ef7ee434/attachment-0001.html>