POSIX mq_receive NULL Priority

[Daniel Hellstrom]

Hello Vincent,

Please follow the links submitted by Joel, they tell you the path and changes. I have merged the 4.10.2 patches and rebuilt the RCC successfully, however I have not had the time to test it as I would 
like, so I have made a temporary Linux release you can download at:

www.gaisler.com/anonftp/rcc/bin/linux/untested_sparc-rtems-4.10-gcc-4.4.6-1.2.9-linux.tar.bz2

The sources can be downloaded as usual at github, make sure to use the rcc-1.2 branch:
https://github.com/daniel-hellstrom/leon-rtems/branches
git clone git://github.com/daniel-hellstrom/leon-rtems.git

Thanks,
Daniel


On 03/18/2013 05:57 PM, Vincent Galbo wrote:
> Thanks guys,
>
> I think I will attempt to patch it myself and remain with this version of
> RTEMS. However, I am having trouble actually finding the mqueuerecvsupp.c
> files in the RTEMS source. Can you direct on how to locate and compile this
> patch into this version of RTEMS?
>
> Thanks again,
> Vincent Galbo
>
> -----Original Message-----
> From: Daniel Hellstrom [mailto:daniel at gaisler.com]
> Sent: Monday, March 18, 2013 12:13 PM
> To: Joel Sherrill
> Cc: Vincent Galbo; rtems-users at rtems.org
> Subject: Re: POSIX mq_receive NULL Priority
>
> Hello All,
>
> Joel, thanks for CC:ing me.
>
> The Gaisler RCC has this problem since we're still on 4.10.1. There are a
> couple of patches from 4.10.1 to 4.10.2, and I have it on my TODO to update
> our RCC release to 4.10.2. Vincent, I will try to find time in the coming
> weeks to rebase RCC to 4.10.2, in the meantime you can apply the patch(es)
> manually or by using the RCC Git repository and then rebuild the kernel
> yourself. If you have further questions about RCC you can mail
> support at gaisler.com.
>
> Regards,
> Daniel
>
>
> On 03/18/2013 04:58 PM, Joel Sherrill wrote:
>> 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