Am Freitag, 26. Mai 2006 18:27 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
>  > Where does the simulator get this configuration from? Can it be changed
>  > to run tests in periodic and aperiodic mode?
> The nucleus look for the parameter "tick_arg". Over kernel-space, this
> parameter is a module parameter; over simulator, this parameter is an
> environment variable. So, running:
> tick_arg=10000000 ./tthread
> should make the test run.
Thanks for your explanation. I will try to integrate this in the test suite.
>  > Would  the test be adapedt to emit a "skipping: periodic mode not
>  > configured" if it is not properly configured?
> An example of bit decay. This test used to be skipped over non periodic
> mode.
That is exactly the point why I try to run the buildbot. Automatic regression 
tests should catch these kind of errors.
> Now, it is repaired.
Thanks a lot. Such quick fixes motivate me to continue my work.

But I get now in
the following error:
Some problems were reported in:
posix->tthread:: tthread.c:91 pthread_join(child1, &tmp) == ESRCH
tthread.c:91 pthread_join(child1, &tmp) == ESRCH

Running libtool --mode=execute gdb ./tthread I can give you the following call 
tthread.c:89 TEST passed.
tthread.c:91 pthread_join(child1, &tmp) == ESRCH

Program received signal SIGSEGV, Segmentation fault.
0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) 
at ../../../ksrc/skins/posix/thread.c:409
409         if (!pse51_obj_active(thread, PSE51_THREAD_MAGIC, struct 
(gdb) info stack
#0  0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) 
at ../../../ksrc/skins/posix/thread.c:409
#1  0x10006734 in root_thread (cookie=0x0) at tthread.c:91
#2  0x1000d728 in thread_trampoline (cookie=0x100d1838) 
at ../../../ksrc/skins/posix/thread.c:56
#3  0x10050f78 in mvm_thread_trampoline_kroot_ ()
#4  0x0ffd10b4 in XenoThread::trampoline_kroot_ () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/
#5  0x0ffd1150 in XenoThread::body () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/
#6  0x0ffd2c58 in MvmThread::life () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/
#7  0x0fba6ad0 in makecontext () from /lib/tls/
Previous frame inner to this frame (corrupt stack?)

Do you have any clue? (Doubling the stack in vm/ didn't help.)

Best regards

Niklaus Giger

Xenomai-core mailing list

Reply via email to