[Xenomai-core] Errors running sim testsuite for vxWorks

[Xenomai-core] Errors running sim testsuite for vxWorks

[Niklaus Giger]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

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

[-- Attachment #2: test_sim --]
[-- Type: application/x-shellscript, Size: 224 bytes --]

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[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 ***
 > 
 > 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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Niklaus Giger]

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

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Philippe Gerum]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Philippe Gerum]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Philippe Gerum]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Philippe Gerum]

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.

Re: [Xenomai-core] Errors running sim testsuite for vxWorks

[Philippe Gerum]

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.