On 12/03/16 11:53, Chris Gransden wrote:
> In article <56E2EDD9.7020802@sky.com>,
> Lee Noar <leenoar@sky.com> wrote:
>> On 05/03/16 17:23, Theo Markettos wrote:
>>> On Sat, Mar 05, 2016 at 04:06:12PM +0100, John Tytgat wrote:
>>>> On 03/01/2016 07:26 PM, Theo Markettos wrote:
>>>>> [...]
>>>>> I can do some implementation and testing, if this is deemed to be
>>>>> a good idea. ('testing' in a loose sense - provoking concurrency
>>>>> conditions being somewhat hard)
>>>>
>>>> FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
>>>> pthread). It might be useful to verify nothing gets obviously
>>>> broken.
>>>
>>> Useful to know.
>
>>> I'll let Lee take the lead since he probably knows more than I about the
>>> internals, but let me know if you need help.
>
>> I've just committed some changes that determine whether to use SWP
>> or LDREX/STREX at runtime using the info that Ben posted as a guide.
>> Perhaps if you have a RPi3, you could see if Otter works?
>
>> I think the pthread testing code may need some work to bring it up
>> to date, plus all the tests need to be built with the -static flag, but
>> that's proving difficult to achieve.
>
> QupZilla and Otter browser seem to run ok at first but then crash with the
> same stack trace. Sometimes straight away or after a couple of minutes use.
> MPlayer also crashes in a silimar way but there is no stack trace. Command
> line programs run OK. Also ArcEm and !Nettle run OK too.
>
> Here's the stack trace from Otter browser,
[snip]
Those programs that don't use pthreads should be okay, it's the
pthread code that's the problem.
I've order a RPi3, so hopefully some hands on experimenting will
help. In the meantime, if anyone can spot the issue, let me know.
Thanks,
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment