[M3devel] thread tester results on ARM_LINUX

[mika at async.caltech.edu]

Antony Hosking writes:
>I wonder of the redzone size for AMD 64 stack frames is not set properly.=20=
>

Tony,

Are you talking about the difference between the ARM and AMD64 results?

The AMD64 is also a machine with 12 logical (HT) processors whereas the
ARM is a single processor.  That could make a difference in how it fails.

By the way, would you know:  The following output on the amd64:

Continuing.
....pthread_mutex_destroy:EBUSY
...pthread_mutex_destroy:EBUSY

Is that an assertion failing in the pthreads library?  My program isn't
printing this stuff: it's coming from ThreadPThread or some such code.

     Mika

>
>Sent from my iPhone
>
>> On Jan 3, 2014, at 10:13 AM, mika at async.caltech.edu wrote:
>>=20
>> (78)raspberrypi:~/cm3-cvs-anon/cm3/m3-libs/m3core/tests/thread>gdb ARM_LIN=
>UX/threadtest
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.ht=
>ml>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"=
>
>> and "show warranty" for details.
>> This GDB was configured as "arm-linux-gnueabihf".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core/tests/th=
>read/ARM_LINUX/threadtest...done.
>> (gdb) handle SIGILL=20
>> Signal        Stop      Print   Pass to program Description
>> SIGILL        Yes       Yes     Yes             Illegal instruction
>> (gdb) handle SIGILL  nostop noprint
>> Signal        Stop      Print   Pass to program Description
>> SIGILL        No        No      Yes             Illegal instruction
>> (gdb) run
>> Starting program: /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core/tests/threa=
>d/ARM_LINUX/threadtest=20
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.=
>1".
>> Writing file...done
>> Creating read threads...[New Thread 0x409f4450 (LWP 2941)]
>> [New Thread 0x40bf4450 (LWP 2942)]
>> [New Thread 0x40df4450 (LWP 2943)]
>> done
>> Creating fork threads...[New Thread 0x40ff4450 (LWP 2944)]
>> [New Thread 0x411f4450 (LWP 2945)]
>> [New Thread 0x413f4450 (LWP 2946)]
>> done
>> Creating alloc threads...[New Thread 0x415f4450 (LWP 2947)]
>> [New Thread 0x417f4450 (LWP 2948)]
>> [New Thread 0x419f4450 (LWP 2949)]
>> done
>> Creating lock threads...[New Thread 0x41bf4450 (LWP 2950)]
>> [New Thread 0x41df4450 (LWP 2951)]
>> [New Thread 0x41ff4450 (LWP 2952)]
>> done
>> running...printing oldest/median age/newest
>>=20
>> Program received signal SIG64, Real-time event 64.
>> [Switching to Thread 0x41ff4450 (LWP 2952)]
>> 0x4028f848 in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnu=
>eabihf/libpthread.so.0
>> (gdb) handle SIG64 nostop noprint
>> Signal        Stop      Print   Pass to program Description
>> SIG64         No        No      Yes             Real-time event 64
>> (gdb) cont
>> Continuing.
>> .
>>=20
>> ***
>> *** runtime error:
>> ***    An array subscript was out of range.
>> ***    file "../src/runtime/common/RTCollector.m3", line 418
>> ***
>>=20
>>=20
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0x40ff4450 (LWP 2944)]
>> 0x402cfbfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
>> (gdb) where
>> #0  0x402cfbfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
>> #1  0x402d397c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
>> #2  0x00000000 in ?? ()
>> (gdb)=20
>>=20
>> It runs fine with user threads on AMD64_LINUX now.  Haven't tried that on
>> ARM_LINUX but would be surprised if it didn't work.
>>=20
>> Yes the pthreads seem "more reliable" than they used to be, but I would
>> never use them in any sort of mission-critical application.  I use
>> Modula-3 programs for (among other things) financial transactions and
>> real-time motor controllers...
>>=20
>>    Mika