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 
http://ngiger.dyndns.org/buildbot/sim/builds/60/step-check_sim/0
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 
stack:
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 
pse51_thread)
(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/libmvm.so.2
#5  0x0ffd1150 in XenoThread::body () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
#6  0x0ffd2c58 in MvmThread::life () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
#7  0x0fba6ad0 in makecontext () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb)                                                

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

Best regards

-- 
Niklaus Giger

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to