Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Philippe Gerum wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Niklaus Giger wrote:
> Do you have any ideas? Thanks in advance.
No idea, the x86 version does not seem to have the same problem, but
valgrind give many errors.
Valgrind chokes on the co-routine switching code, which is fair
enough, since it's quite hard for it to track stack context changes
the way setcontext/getcontext do it.
However, like for the previous stack size issue with satch.c, I wonder
if the fixed-size stacks allocated by the simulator for its threads
are not overflowed.
Does this patch make the situation any better?
--- sim/vm/thread.cc(revision 1083)
+++ sim/vm/thread.cc(working copy)
@@ -900,7 +900,7 @@
void *_faddr,
int _pflags,
const char *_name) :
-MvmThread(_name,_pflags|MVM_THREAD_CLIENT,16384)
+MvmThread(_name,_pflags|MVM_THREAD_CLIENT,32768)
{
tcbarg = _tcbarg;
faddr = _faddr;
This one is better:
--- sim/vm/thread.cc(revision 1083)
+++ sim/vm/thread.cc(working copy)
@@ -900,7 +900,7 @@
void *_faddr,
int _pflags,
const char *_name) :
-MvmThread(_name,_pflags|MVM_THREAD_CLIENT,16384)
+MvmThread(_name,_pflags|MVM_THREAD_CLIENT,32768)
{
tcbarg = _tcbarg;
faddr = _faddr;
@@ -915,7 +915,7 @@
}
XenoThread::XenoThread (const char *_name) :
-MvmThread(_name,MVM_IFACE_HIDDEN,16384)
+MvmThread(_name,MVM_IFACE_HIDDEN,32768)
{
tcbarg = NULL;
faddr = NULL;
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Niklaus Giger wrote:
> Do you have any ideas? Thanks in advance.
No idea, the x86 version does not seem to have the same problem, but
valgrind give many errors.
Valgrind chokes on the co-routine switching code, which is fair enough,
since it's quite hard for it to track stack context changes the way
setcontext/getcontext do it.
However, like for the previous stack size issue with satch.c, I wonder
if the fixed-size stacks allocated by the simulator for its threads are
not overflowed.
Does this patch make the situation any better?
--- sim/vm/thread.cc(revision 1083)
+++ sim/vm/thread.cc(working copy)
@@ -900,7 +900,7 @@
void *_faddr,
int _pflags,
const char *_name) :
-MvmThread(_name,_pflags|MVM_THREAD_CLIENT,16384)
+MvmThread(_name,_pflags|MVM_THREAD_CLIENT,32768)
{
tcbarg = _tcbarg;
faddr = _faddr;
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Gilles Chanteperdrix wrote: Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > > > > > > Is it normal that a "make check" only works, if one builds the simulator > > > inside the source code? > > > > Last time I checked it worked when built out-of-tree, but you must build > > the simulator in the sim subdirectory of a xenomai build directory. > > It should not be necessary, at least I don't build it this way and it > works. This is not a guarantee of success for the "make check" issue though. out of tree make check works here. It is the simulator _sources_ that must be put in a sub-directory of the xenomai sources. Yep. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > > > > > > Is it normal that a "make check" only works, if one builds the > > simulator > > > inside the source code? > > > > Last time I checked it worked when built out-of-tree, but you must build > > the simulator in the sim subdirectory of a xenomai build directory. > > It should not be necessary, at least I don't build it this way and it > works. This is not a guarantee of success for the "make check" issue though. out of tree make check works here. It is the simulator _sources_ that must be put in a sub-directory of the xenomai sources. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Gilles Chanteperdrix wrote: Niklaus Giger wrote: > Do you have any ideas? Thanks in advance. No idea, the x86 version does not seem to have the same problem, but valgrind give many errors. Valgrind chokes on the co-routine switching code, which is fair enough, since it's quite hard for it to track stack context changes the way setcontext/getcontext do it. However, like for the previous stack size issue with satch.c, I wonder if the fixed-size stacks allocated by the simulator for its threads are not overflowed. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Gilles Chanteperdrix wrote: > Is it normal that a "make check" only works, if one builds the simulator > inside the source code? Last time I checked it worked when built out-of-tree, but you must build the simulator in the sim subdirectory of a xenomai build directory. It should not be necessary, at least I don't build it this way and it works. This is not a guarantee of success for the "make check" issue though. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Niklaus Giger wrote: > Do you have any ideas? Thanks in advance. No idea, the x86 version does not seem to have the same problem, but valgrind give many errors. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Am Donnerstag, 11. Mai 2006 18:51 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
> > Hi
> >
> > Running the sim testsuite vxworks (revision 1078) (using the attached
> > script) I get the following a few failures and memory corruption:
> >
> > trestart.c:46, taskSpawn("nop", 19, 0, 32768, nopTask,
> > 0,0,0,0,0,0,0,0,0,0) != ERROR
> > *** glibc detected *** malloc(): memory corruption: 0x100bf000 ***
Okay. Calling gdb .libs/trestart gave me the following output:
(gdb) run
Starting
program:
/mnt/data.ng/buildslave/buildbot/quick-sim/build/sim/skins/vxworks/testsuite/.libs/trestart
Xenomai/sim: real-time nucleus v2.2-dev (Engines Of Creation) loaded.
starting VxWorks services.
trestart.c:85, taskSpawn("create", 20, 0, 32768, createTask,
0,0,0,0,0,0,0,0,0,0) != ERROR
trestart.c:85 TEST passed.
trestart.c:87, semTake(restart_test_end, WAIT_FOREVER) == OK
trestart.c:46, taskSpawn("nop", 19, 0, 32768, nopTask, 0,0,0,0,0,0,0,0,0,0) !=
ERROR
trestart.c:46 TEST passed.
trestart.c:50, taskRestart(0) != ERROR
trestart.c:46, taskSpawn("nop", 19, 0, 32768, nopTask, 0,0,0,0,0,0,0,0,0,0) !=
ERROR
*** glibc detected *** malloc(): memory corruption: 0x100be000 ***
Program received signal SIGABRT, Aborted.
0x0fba77bc in raise () from /lib/tls/libc.so.6
(gdb) info stack
#0 0x0fba77bc in raise () from /lib/tls/libc.so.6
#1 0x0fba92c0 in abort () from /lib/tls/libc.so.6
#2 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#3 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#4 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#5 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#6 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#7 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#8 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#9 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#10 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#11 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#12 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#13 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#14 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#15 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#16 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
#17 0x0fbe1f60 in __fsetlocking () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb)
Do you have any ideas? Thanks in advance.
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Gilles Chanteperdrix wrote:
> Niklaus Giger wrote:
> > Hi
> >
> > Running the sim testsuite vxworks (revision 1078) (using the attached
> script)
> > I get the following a few failures and memory corruption:
> >
> > trestart.c:46, taskSpawn("nop", 19, 0, 32768, nopTask,
> 0,0,0,0,0,0,0,0,0,0) !=
> > ERROR
> > *** glibc detected *** malloc(): memory corruption: 0x100bf000 ***
> >
> > t010726-1.log:t010726-1.c:106, test finished: 4 failures/ 15 tests
> > t010726-2.log:t010726-2.c:224, test finished: 0 failures/ 82 tests
> > t010728.log:t010728.c:119, test finished: 0 failures/ 4 tests
> > t010820-1.log:t010820-1.c:90, test finished: 0 failures/ 23 tests
> > t010820-2.log:t010820-2.c:81, test finished: 0 failures/ 11 tests
> > t010823-1.log:t010823-1.c:114, test finished: 0 failures/ 16 tests
> > t010823-2.log:t010823-2.c:166, test finished: 1 failures/ 33 tests
> >
> > Is this normal or a powerpc specific error of the Xenomai simulator?
>
> The tests run here without any failure, however the round-robin test
> relies on a precise number of "virtual cycles" which is probably
> architecture dependent.
Ok, I get the errors too.
Counts of "virtual cycles" depend on the count of lines in the source
program, so are architecture independent. But they have been divided by
ten, because vxworks tick rate is now 1000 whereas it used to be 100.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Errors running sim testsuite for vxWorks
Niklaus Giger wrote:
> Hi
>
> Running the sim testsuite vxworks (revision 1078) (using the attached
> script)
> I get the following a few failures and memory corruption:
>
> trestart.c:46, taskSpawn("nop", 19, 0, 32768, nopTask, 0,0,0,0,0,0,0,0,0,0)
> !=
> ERROR
> *** glibc detected *** malloc(): memory corruption: 0x100bf000 ***
>
> t010726-1.log:t010726-1.c:106, test finished: 4 failures/ 15 tests
> t010726-2.log:t010726-2.c:224, test finished: 0 failures/ 82 tests
> t010728.log:t010728.c:119, test finished: 0 failures/ 4 tests
> t010820-1.log:t010820-1.c:90, test finished: 0 failures/ 23 tests
> t010820-2.log:t010820-2.c:81, test finished: 0 failures/ 11 tests
> t010823-1.log:t010823-1.c:114, test finished: 0 failures/ 16 tests
> t010823-2.log:t010823-2.c:166, test finished: 1 failures/ 33 tests
>
> Is this normal or a powerpc specific error of the Xenomai simulator?
The tests run here without any failure, however the round-robin test
relies on a precise number of "virtual cycles" which is probably
architecture dependent.
In order to display the errors, you should grep '^[^ ]*:[0-9]*:' in the
logs.
>
> How do I debug trestart as it is not a fully linked executable?
trestart is a script, the fully linked executable is in the .libs
directory, because of libtool. There is a way to run gdb using the
script arguments, which I do not remember, something like
--mode=exec gdb
> Is it normal that a "make check" only works, if one builds the simulator
> inside the source code?
Last time I checked it worked when built out-of-tree, but you must build
the simulator in the sim subdirectory of a xenomai build directory.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Errors running sim testsuite for vxWorks
Hi
Running the sim testsuite vxworks (revision 1078) (using the attached script)
I get the following a few failures and memory corruption:
trestart.c:46, taskSpawn("nop", 19, 0, 32768, nopTask, 0,0,0,0,0,0,0,0,0,0) !=
ERROR
*** glibc detected *** malloc(): memory corruption: 0x100bf000 ***
t010726-1.log:t010726-1.c:106, test finished: 4 failures/ 15 tests
t010726-2.log:t010726-2.c:224, test finished: 0 failures/ 82 tests
t010728.log:t010728.c:119, test finished: 0 failures/ 4 tests
t010820-1.log:t010820-1.c:90, test finished: 0 failures/ 23 tests
t010820-2.log:t010820-2.c:81, test finished: 0 failures/ 11 tests
t010823-1.log:t010823-1.c:114, test finished: 0 failures/ 16 tests
t010823-2.log:t010823-2.c:166, test finished: 1 failures/ 33 tests
Is this normal or a powerpc specific error of the Xenomai simulator?
How do I debug trestart as it is not a fully linked executable?
Is it normal that a "make check" only works, if one builds the simulator
inside the source code?
Thanks for any suggestion.
Best regards
--
Niklaus Giger
test_sim
Description: application/shellscript
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
