Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-22 Thread Philippe Gerum
On Sat, 2010-08-21 at 19:36 +0200, Gilles Chanteperdrix wrote:
 Gilles Chanteperdrix wrote:
  There are other issues to consider, such as detecting that a private
  mutex created in the father continues to be used in the child.
 
 A simple fix for this would be to keep a list of mutexes in the native
 and posix skin, and nullify their magic/opaque pointer at fork. The
 problem is that there is no more room in pthread_mutex_t, so we will
 have to malloc at pthread_mutex_init time.
 

Please simply issue a warning as you suggested once when a potentially
dangerous situation arises upon fork regarding mutexes. Piling up
non-trivial code to prevent an obviously broken application from
misbehaving even more is way too expensive if such code could introduce
more overhead, and potentially secondary mode switches.

IIUC, we are discussing about apps using in a child context some private
mutexes which were initially created in the parent context, right? If
so, then a warning upon detection should suffice to have the author go
back to the drawing board, and optionally run man pthread_mutex_init
as well.

-- 
Philippe.



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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-22 Thread Gilles Chanteperdrix
Philippe Gerum wrote:
 On Sat, 2010-08-21 at 19:36 +0200, Gilles Chanteperdrix wrote:
 Gilles Chanteperdrix wrote:
 There are other issues to consider, such as detecting that a private
 mutex created in the father continues to be used in the child.
 A simple fix for this would be to keep a list of mutexes in the native
 and posix skin, and nullify their magic/opaque pointer at fork. The
 problem is that there is no more room in pthread_mutex_t, so we will
 have to malloc at pthread_mutex_init time.

 
 Please simply issue a warning as you suggested once when a potentially
 dangerous situation arises upon fork regarding mutexes. Piling up
 non-trivial code to prevent an obviously broken application from
 misbehaving even more is way too expensive if such code could introduce
 more overhead, and potentially secondary mode switches.
 
 IIUC, we are discussing about apps using in a child context some private
 mutexes which were initially created in the parent context, right? If
 so, then a warning upon detection should suffice to have the author go
 back to the drawing board, and optionally run man pthread_mutex_init
 as well.

Ok. Detection is not that easy with fastsyncs, so here what I set up to do:
- for mutexes going through the syscall path, return EPERM (the
documented error for that case), and print a message inn the console.
- for mutexes going through fastsync, cause a segmentation fault to kill
the application by setting up an inaccessible mapping where the private
heap was, this is better than potential silent memory corruption (the
current situation). But needs be documented.

-- 
Gilles.

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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-21 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Fri, 2010-08-20 at 11:54 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 Yes, now if you find the culprit option, it would be nice to report here
 so that we can fix the I-pipe patch.


 I do know it still. All i have are two configs. One which does not work
 and one working. I have tried so far breaking working one and also
 fixing broken. Both attempts have been unsuccessful.

 I tried many obvious settings mainly in processor type and features
 with no luck.

 This process must take some time ( i can't spend whole days on trying
 one-by-one each difference, recompile kernel,ync target's rootfs,
 reboot target and run fork regression test even that many steps i have
 automated)
 ever heard about bisecting ?
 
 sure i had.
 
 
  List the diffs between the two configs
 apply half of them
 if it still works, apply half of the rest
 if it does not unapply half of the one you applied
 etc...
 if there are 65000 differences, you will get to the result in 16 steps.
 you can keep the same rootfs, all you have to do is rebuild the kernel
 (without make clean, so that only what changed in the .config is
 re-compiled).

 
 i used to use more fine grained changes set until it made me tired.
 
 and i as you may know most changes in processor features lead to
 recompile whole kernel - by not cleaning won't save anything.
 
 
 It should take just an hour or two.
 
 poss. but i don't think so.

Well actually, bisecting was not the right approach, debugging the
segfault directly worked much better. We have only two atfork handlers,
and one is in the posix skin which Krzysztof test does not use, so we
knew where the bug was...

Anyway, here is the explanation: it is a big fastsync bug. In the atfork
handler, we unmap the father's private semaphore heap, in order to map
the child's private semaphore heap. In order to find the heap size, the
unmapping code issues a system call wich ends up looking for the thread
ppd, in order to find its private heap. The problem is that the thread
has not yet bound any skin, so it has no ppd, and it ends up using the
global ppd instead.

As long as the two heaps use the same size, it works, however, if they
have different sizes, we get a segmentation fault upon the call to munmap.

But that is not the worse: after unmapping the father's private heap, we
try and map the child's private heap. Here again, we issue the system
call, and here again, we get the global semaphore heaps data, this means
that the global semaphore heap gets used instead of the child's private
semaphore heap. That is definitely a bug, and would cause all sorts of bugs.

Even worse yet, we find that since the child process has not bound any
skin, it is unable to use skins services properly. Only the posix skin
rebinds itself at fork.

So, I propose the following fix:
- in the semaphore heaps atfork handler, unmap the private heap (using
the size which was used at map time), do not remap it.
- register atfork handlers for all skins, in order to rebind them after
fork, so that the skin services may be used in the child, the fork
handler will

There are other issues to consider, such as detecting that a private
mutex created in the father continues to be used in the child.

Any comments, anyone?

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-21 Thread Gilles Chanteperdrix
Gilles Chanteperdrix wrote:
 There are other issues to consider, such as detecting that a private
 mutex created in the father continues to be used in the child.

A simple fix for this would be to keep a list of mutexes in the native
and posix skin, and nullify their magic/opaque pointer at fork. The
problem is that there is no more room in pthread_mutex_t, so we will
have to malloc at pthread_mutex_init time.

-- 
Gilles.

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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-20 Thread Krzysztof Błaszkowski

 Yes, now if you find the culprit option, it would be nice to report here
 so that we can fix the I-pipe patch.
 


I do know it still. All i have are two configs. One which does not work
and one working. I have tried so far breaking working one and also
fixing broken. Both attempts have been unsuccessful.

I tried many obvious settings mainly in processor type and features
with no luck.

This process must take some time ( i can't spend whole days on trying
one-by-one each difference, recompile kernel, sync target's rootfs,
reboot target and run fork regression test even that many steps i have
automated)

Regards,
-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-20 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 Yes, now if you find the culprit option, it would be nice to report here
 so that we can fix the I-pipe patch.

 
 
 I do know it still. All i have are two configs. One which does not work
 and one working. I have tried so far breaking working one and also
 fixing broken. Both attempts have been unsuccessful.
 
 I tried many obvious settings mainly in processor type and features
 with no luck.
 
 This process must take some time ( i can't spend whole days on trying
 one-by-one each difference, recompile kernel,ync target's rootfs,
 reboot target and run fork regression test even that many steps i have
 automated)

ever heard about bisecting ? List the diffs between the two configs
apply half of them
if it still works, apply half of the rest
if it does not unapply half of the one you applied
etc...
if there are 65000 differences, you will get to the result in 16 steps.
you can keep the same rootfs, all you have to do is rebuild the kernel
(without make clean, so that only what changed in the .config is
re-compiled).

It should take just an hour or two.

 
 Regards,


-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-20 Thread Krzysztof Błaszkowski
On Fri, 2010-08-20 at 11:54 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  Yes, now if you find the culprit option, it would be nice to report here
  so that we can fix the I-pipe patch.
 
  
  
  I do know it still. All i have are two configs. One which does not work
  and one working. I have tried so far breaking working one and also
  fixing broken. Both attempts have been unsuccessful.
  
  I tried many obvious settings mainly in processor type and features
  with no luck.
  
  This process must take some time ( i can't spend whole days on trying
  one-by-one each difference, recompile kernel,ync target's rootfs,
  reboot target and run fork regression test even that many steps i have
  automated)
 
 ever heard about bisecting ?

sure i had.


  List the diffs between the two configs
 apply half of them
 if it still works, apply half of the rest
 if it does not unapply half of the one you applied
 etc...
 if there are 65000 differences, you will get to the result in 16 steps.
 you can keep the same rootfs, all you have to do is rebuild the kernel
 (without make clean, so that only what changed in the .config is
 re-compiled).
 

i used to use more fine grained changes set until it made me tired.

and i as you may know most changes in processor features lead to
recompile whole kernel - by not cleaning won't save anything.


 It should take just an hour or two.

poss. but i don't think so.

Regards,

 
  
  Regards,
 
 


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 00:59 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  Hello,
  
  I found recently that large application uses to segfault before fork()
  leaves its glibc wrapper.
  
  I included here a test suite which can be easily used to verify what
  goes wrong. It may be necessary to adjust makefile to compile the code.
  So, the console is missing output from line #89. We can see instead a
  message that getpid couldn't be linked which is 1st sign of memory
  corruption.
  
  i used to think that this issue could be related to not unbinding heap
  before fork() but it turned out that it is enough to link userspace with
  xenomai libraries.
  
  I wonder if this is known issue and if there is any fix, does 2.5.4 work
  same ? or maybe there is something wrong with the kernel i use (or adeos
  patch)
  
  Another question is why rt_task_create() is marked deprecated in native
  skin. Does it mean that native skin is going to be removed from source
  tree ?
 
 Ok. Tried your test on:
 - 2.6.33 armv5
 - 2.6.34 x86_64
 - 2.6.31 x86_64
 - 2.6.31 x86_32
 
 And everything works fine.
 
 The result of the last experience is:
 # xeno-shmem-fork
 main:43 heap 0xb76be000
 /root
 main:60 [4365] pid 4367
 main:53
 main:54 [4367] pid 0
 main:63 [4365] pid 4367, status 0b00
 main:64 [4365] pid 4367, WIFSIGNALED 0, WIFEXITED 1, rc 11
 0
 # cat /proc/ipipe/version
 2.4-09
 # cat /proc/xenomai/version
 2.5.4
 # uname -a
 Linux atom 2.6.31.8 #5 SMP Wed Aug 18 00:44:17 CEST 2010 i686 GNU/Linux
 
 There does not seem to be anything wrong in xenomai rt_heap code, as
 this code is platform-independent, so if there was something wrong with
 it, we would see it on all platforms.
 
 Some clues about what could be wrong:
 - I am not sure your makefile works: the .o file has the same name for
 the kernel module and the executable. I do not think this could matter
 (if you could get it wrong, the module or the executable would not run),
 but in any case, this is a bad idea, and since the kernel module and
 user-space application do not share any code, it seems simpler to put
 them in separate files.

in this example having both kernel and userland in one single file
doesn't matter because userland is compiled without any inter-linking
stage (-c switch, also i could different object names, so it is ok). gcc
produces directly executable.

i removed any objects and just commented out building kernel part since
i have got this already.

new executable works the same way as previous on my atom.



 - I have not really checked your user-space compilation flags, I am
 using xeno-config to get the correct ones.

xeno-config --skin=native --cflags gives:

-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__


note that there is no xenomai installed on my rd server
in /usr/xenomai/

i build xenomai per kernel and install it in kernel's INSTALL sub-dir
(DESTDIR=) as well as kernel's modules and other related stuff for this
particular kernel.
(otherwise i would go mad soon due to various versions ..)


xeno-config --skin=native --ldflags gives:

-lnative -L/usr/xenomai/lib -lxenomai -lpthread

and indeed i missed libpthread but otoh userland without pthread even
does not depend directly on pthreads:

ldd xeno-shmem-fork
linux-gate.so.1 =  (0xe000)
libnative.so.3 = not found
libxenomai.so.0 = not found
libc.so.6 = /lib/libc.so.6 (0xf7da5000)
/lib/ld-linux.so.2 (0xf7f1)

when compiled without pthreads.


*ANYWAY* with pthreads i got exactly what i observed in the app i am
interested in. (build process is properly configured according to the
art ie without any simplifications i did in my makefile)


atest:~/xeno-test-254 # ./.try.sh
main:79 heap 0x401be000
/root/xeno-test-254
main:96 [1062] pid 1064
main:99 [1062] pid 1064, status 000b
main:100 [1062] pid 1064, WIFSIGNALED 1, WIFEXITED 0, rc 0
4
atest:~/xeno-test-254 # 


children got a signal.

i added also exact cflags from xeno-config. these cflags don't change
anything, so with libpthread children segfaults, without it getpid()
can't be resolved in children process still.


 - your user-space code was missing #include unistd.h

i added. it changed nothing.


 - some subtle difference in the glibc

hmm, i'd say that is rather out my control. i use by default opensuse
for rd.

does this mean that this distro is broken ?

(otoh many things are - especially gnome)

 - some x86_32 specific I-pipe bug triggered by some kernel configuration
 option

i can send config if you like.


 - some local patches in your kernel
 

i use now nothing except adeos for testing fork. i use also
compiled-in driver for rtl8103 which is out of kernel tree but i don't
think it could induce this issue. i reckon probability is close to 0.0
and without driver target is useless. (it is 100% diskless rd test box)

 In any case, without further information, it is hard for me to dig any
 further tonight. Regards.

i see. 

Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 i see. want you me to send .config file ? anything else ?

Have you tried gdb? It should tell you exactly at what point the binary
takes the signal.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 13:00 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 00:59 +0200, Gilles Chanteperdrix wrote:
  - I have not really checked your user-space compilation flags, I am
  using xeno-config to get the correct ones.
  
  xeno-config --skin=native --cflags gives:
  
  -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__
  
  
  note that there is no xenomai installed on my rd server
  in /usr/xenomai/
  
  i build xenomai per kernel and install it in kernel's INSTALL sub-dir
  (DESTDIR=) as well as kernel's modules and other related stuff for this
  particular kernel.
  (otherwise i would go mad soon due to various versions ..)
 
 xeno-config handles the DESTDIR environment variable (failing to do this
 would be kind of silly, because a lot of people, including the
 maintainers, use Xenomai mostly in cross-compiled environment).

no, it does not.

./xeno-config
xeno-config --verbose
--version=2.5.4
--cc=gcc
--arch=x86
--prefix=/usr/xenomai
--xeno-cflags=-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT
-Wall -pipe -D__XENO__
--xeno-ldflags=-L/usr/xenomai/lib -lxenomai -lpthread 
--posix-cflags=
POSIX support is not available
--posix-ldflags=
--library-dir=/usr/xenomai/lib
Usage xeno-config --skin=skinname OPTIONS
Options :
--help
--v,--verbose
--version
--cc
--arch
--prefix
--skin native|posix|psos|rtai|rtdm|uitron|vrtx|vxworks
--cflags
--ldflags
--lib*-dir,--libdir,--user-libdir

Deprecated options:
--xeno-cflags
--xeno-ldflags
--posix-cflags
--posix-ldflags


while it was built like this:

make DESTDIR=/root/... install



 
  xeno-config --skin=native --ldflags gives:
  
  -lnative -L/usr/xenomai/lib -lxenomai -lpthread
  
  and indeed i missed libpthread but otoh userland without pthread even
  does not depend directly on pthreads:
  
  ldd xeno-shmem-fork
  linux-gate.so.1 =  (0xe000)
  libnative.so.3 = not found
  libxenomai.so.0 = not found
  libc.so.6 = /lib/libc.so.6 (0xf7da5000)
  /lib/ld-linux.so.2 (0xf7f1)
  
  when compiled without pthreads.
 
 libnative depends on pthread, if ldd had been able to find libnative, it
  would have found the dependency on libpthread.


but there is still a difference in xeno-shmem-fork behavior when linked
with pthread or not from command line.


 
 
  - your user-space code was missing #include unistd.h
  
  i added. it changed nothing.
 
 Ok, with all other changes I assume?

i added them and tried incrementally but final source/makefile have all
these features.

 
  - some subtle difference in the glibc
  
  hmm, i'd say that is rather out my control. i use by default opensuse
  for rd.
  
  does this mean that this distro is broken ?
  
  (otoh many things are - especially gnome)
 
 What version of opensuse?

11.1 - 32. i do not crosscompile on x86_64 to x86 because i have
encountered various strange mismatches in the past.

rather i use native clean x86 environment (on e.g. x86_64)


  If several toolchains are available, which one
 are you using?

i use default only. (and i think there is only one)
gcc -v gives:

Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)

  I do not mean to say that the glibc is broken, only that
 xenomai could use it in a way that breaks with the version you are using.

maybe, let's investigate this further.

 
  In any case, without further information, it is hard for me to dig any
  further tonight. Regards.
  
  i see. want you me to send .config file ? anything else ?
 
 Run cat /proc/ipipe/version /proc/xenomai/version, uname and getconf
 GNU_LIBPTHREAD_VERSION on the target, in order to get sure that you run
 the versions you think you are running. Then please send your .config.
 
 Please also send a full kernel log, from the boot, up to the bug.
 

welcome.
 cat /proc/ipipe/version 
2.4-09
atest:~/xeno-test-254 # cat /proc/xenomai/version 
2.5.4
atest:~/xeno-test-254 # getconf
bash: getconf: command not found
atest:~/xeno-test-254 # getconf GNU_LIBPTHREAD_VERSION
NPTL 2.9
atest:~/xeno-test-254 # uname -a

Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 13:00 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 00:59 +0200, Gilles Chanteperdrix wrote:
 - I have not really checked your user-space compilation flags, I am
 using xeno-config to get the correct ones.
 xeno-config --skin=native --cflags gives:

 -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__


 note that there is no xenomai installed on my rd server
 in /usr/xenomai/

 i build xenomai per kernel and install it in kernel's INSTALL sub-dir
 (DESTDIR=) as well as kernel's modules and other related stuff for this
 particular kernel.
 (otherwise i would go mad soon due to various versions ..)
 xeno-config handles the DESTDIR environment variable (failing to do this
 would be kind of silly, because a lot of people, including the
 maintainers, use Xenomai mostly in cross-compiled environment).
 
 no, it does not.
 
 ./xeno-config
 xeno-config --verbose
 --version=2.5.4
 --cc=gcc
 --arch=x86
 --prefix=/usr/xenomai
 --xeno-cflags=-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT
 -Wall -pipe -D__XENO__
 --xeno-ldflags=-L/usr/xenomai/lib -lxenomai -lpthread 
 --posix-cflags=
 POSIX support is not available
 --posix-ldflags=
 --library-dir=/usr/xenomai/lib
 Usage xeno-config --skin=skinname OPTIONS
 Options :
 --help
 --v,--verbose
 --version
 --cc
 --arch
 --prefix
 --skin native|posix|psos|rtai|rtdm|uitron|vrtx|vxworks
 --cflags
 --ldflags
 --lib*-dir,--libdir,--user-libdir
 
 Deprecated options:
 --xeno-cflags
 --xeno-ldflags
 --posix-cflags
 --posix-ldflags
 
 
 while it was built like this:
 
 make DESTDIR=/root/... install

You are not paying attention. I said it handles the DESTDIR environment
 variable. So, you should pass DESTDIR as an environment variable to
xeno-config. As in:

DESTDIR=/root/ xeno-config --skin=native --cflags

The xeno-config script is built when Xenomai is compiled, not installed,
at this point, it would be against the rules to assume that a DESTDIR is
set, and hardcode a DESTDIR value into xeno-config.

See GNU make documentation:
http://www.gnu.org/software/make/manual/html_node/DESTDIR.html

And for a good reason, the final destination of Xenomai on your system
may be different from where you initially installed it. So, handling
DESTDIR dynamically in xeno-config makes things more flexible.

 but there is still a difference in xeno-shmem-fork behavior when linked
 with pthread or not from command line.

Ok. But linking with pthread is the only supported way of using Xenomai. A
 What version of opensuse?
 
 11.1 - 32. i do not crosscompile on x86_64 to x86 because i have
 encountered various strange mismatches in the past.
 
 rather i use native clean x86 environment (on e.g. x86_64)

I do this all the time, and never had any problem.
Also, why not running 64 bits code on your atom? There are some x86_32
only atoms? What about SMP?

By the way, did you forget to semd me your .config ?

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 14:00 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 13:00 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 00:59 +0200, Gilles Chanteperdrix wrote:
  - I have not really checked your user-space compilation flags, I am
  using xeno-config to get the correct ones.
  xeno-config --skin=native --cflags gives:
 
  -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__
 
 
  note that there is no xenomai installed on my rd server
  in /usr/xenomai/
 
  i build xenomai per kernel and install it in kernel's INSTALL sub-dir
  (DESTDIR=) as well as kernel's modules and other related stuff for this
  particular kernel.
  (otherwise i would go mad soon due to various versions ..)
  xeno-config handles the DESTDIR environment variable (failing to do this
  would be kind of silly, because a lot of people, including the
  maintainers, use Xenomai mostly in cross-compiled environment).
  
  no, it does not.
  
  ./xeno-config
  xeno-config --verbose
  --version=2.5.4
  --cc=gcc
  --arch=x86
  --prefix=/usr/xenomai
  --xeno-cflags=-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT
  -Wall -pipe -D__XENO__
  --xeno-ldflags=-L/usr/xenomai/lib -lxenomai -lpthread 
  --posix-cflags=
  POSIX support is not available
  --posix-ldflags=
  --library-dir=/usr/xenomai/lib
  Usage xeno-config --skin=skinname OPTIONS
  Options :
  --help
  --v,--verbose
  --version
  --cc
  --arch
  --prefix
  --skin native|posix|psos|rtai|rtdm|uitron|vrtx|vxworks
  --cflags
  --ldflags
  --lib*-dir,--libdir,--user-libdir
  
  Deprecated options:
  --xeno-cflags
  --xeno-ldflags
  --posix-cflags
  --posix-ldflags
  
  
  while it was built like this:
  
  make DESTDIR=/root/... install
 
 You are not paying attention. 


happens. i recall you spent an hour yesterday on inquiring libc.so
instead of looking into test program output and its source.


 I said it handles the DESTDIR environment
  variable. So, you should pass DESTDIR as an environment variable to
 xeno-config. As in:


fine. this will simplify scripts machinery.


 
 DESTDIR=/root/ xeno-config --skin=native --cflags
 
 The xeno-config script is built when Xenomai is compiled, not installed,
 at this point, it would be against the rules to assume that a DESTDIR is
 set, and hardcode a DESTDIR value into xeno-config.
 
 See GNU make documentation:
 http://www.gnu.org/software/make/manual/html_node/DESTDIR.html
 
 And for a good reason, the final destination of Xenomai on your system
 may be different from where you initially installed it. So, handling
 DESTDIR dynamically in xeno-config makes things more flexible.
 
  but there is still a difference in xeno-shmem-fork behavior when linked
  with pthread or not from command line.
 
 Ok. But linking with pthread is the only supported way of using Xenomai. A
  What version of opensuse?
  
  11.1 - 32. i do not crosscompile on x86_64 to x86 because i have
  encountered various strange mismatches in the past.
  
  rather i use native clean x86 environment (on e.g. x86_64)
 
 I do this all the time, and never had any problem.

i had lots with header files mainly.
and i am happy with my way.

 Also, why not running 64 bits code on your atom? There are some x86_32
 only atoms? What about SMP?

for some other constraints i will not mention i use 32 bits now.

this is single core cpu so no point to use smp for e.g. 8 cpus (nor
bigsmp)

 
 By the way, did you forget to semd me your .config ?
 

it should be included in the kernel.tgz i have sent already.


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 rather i use native clean x86 environment (on e.g. x86_64)
 I do this all the time, and never had any problem.
 
 i had lots with header files mainly.

Well, the glibc and Xenomai header files are the same on 64 bits and 32
bits machines... of course, if you are talking about other libs...

 and i am happy with my way.
 
 Also, why not running 64 bits code on your atom? There are some x86_32
 only atoms? What about SMP?
 
 for some other constraints i will not mention i use 32 bits now.
 
 this is single core cpu so no point to use smp for e.g. 8 cpus (nor
 bigsmp)

Well, my atom has hyper-threading, so, SMP can be used, Linux sees two
threads. I suspect yours has hyper-threading too, since Linux mentions
that it sees an ACPI SMP table, but usually, hyper-threading needs to be
enabled at BIOS level.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 14:37 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  rather i use native clean x86 environment (on e.g. x86_64)
  I do this all the time, and never had any problem.
  
  i had lots with header files mainly.
 
 Well, the glibc and Xenomai header files are the same on 64 bits and 32
 bits machines... of course, if you are talking about other libs...


;) i don't mean Xenomai and degree of crosscompilation complexity
depends on what you try to compile.
i remember a few years ago it was not so funny.

 
  and i am happy with my way.
  
  Also, why not running 64 bits code on your atom? There are some x86_32
  only atoms? What about SMP?
  
  for some other constraints i will not mention i use 32 bits now.
  
  this is single core cpu so no point to use smp for e.g. 8 cpus (nor
  bigsmp)
 
 Well, my atom has hyper-threading, so, SMP can be used, Linux sees two
 threads. I suspect yours has hyper-threading too, since Linux mentions
 that it sees an ACPI SMP table, but usually, hyper-threading needs to be
 enabled at BIOS level.
 

yes, it has ht. disabled now. i thought that i don't want to try to
solve superposition of various corner cases and stuck on solving this.

otoh, i could create such case. did i ?

(btw, rtai 3.7 works)


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 14:37 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 rather i use native clean x86 environment (on e.g. x86_64)
 I do this all the time, and never had any problem.
 i had lots with header files mainly.
 Well, the glibc and Xenomai header files are the same on 64 bits and 32
 bits machines... of course, if you are talking about other libs...
 
 
 ;) i don't mean Xenomai and degree of crosscompilation complexity
 depends on what you try to compile.
 i remember a few years ago it was not so funny.
 
 and i am happy with my way.

 Also, why not running 64 bits code on your atom? There are some x86_32
 only atoms? What about SMP?
 for some other constraints i will not mention i use 32 bits now.

 this is single core cpu so no point to use smp for e.g. 8 cpus (nor
 bigsmp)
 Well, my atom has hyper-threading, so, SMP can be used, Linux sees two
 threads. I suspect yours has hyper-threading too, since Linux mentions
 that it sees an ACPI SMP table, but usually, hyper-threading needs to be
 enabled at BIOS level.

 
 yes, it has ht. disabled now. i thought that i don't want to try to
 solve superposition of various corner cases and stuck on solving this.
 
 otoh, i could create such case. did i ?
 
 (btw, rtai 3.7 works)

This does not give us any clue, since neither the I-pipe patch nor the
heap code are shared. But as I said, I suspect the bug is rather in the
kernel configuration than anywhere else.

We are going to try something else. The .config I use on my atom is here:
http://git.xenomai.org/?p=mkrootfs.git;a=blob_plain;f=boards/generic/atom-32/config-2.6.31;hb=HEAD

Could you start from this configuration, adding only what is needed to
boot your box (root filesystem device controller, or network controller
if booting over nfs, root filesystem), then test this kernel?

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 15:39 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 14:37 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  rather i use native clean x86 environment (on e.g. x86_64)
  I do this all the time, and never had any problem.
  i had lots with header files mainly.
  Well, the glibc and Xenomai header files are the same on 64 bits and 32
  bits machines... of course, if you are talking about other libs...
  
  
  ;) i don't mean Xenomai and degree of crosscompilation complexity
  depends on what you try to compile.
  i remember a few years ago it was not so funny.
  
  and i am happy with my way.
 
  Also, why not running 64 bits code on your atom? There are some x86_32
  only atoms? What about SMP?
  for some other constraints i will not mention i use 32 bits now.
 
  this is single core cpu so no point to use smp for e.g. 8 cpus (nor
  bigsmp)
  Well, my atom has hyper-threading, so, SMP can be used, Linux sees two
  threads. I suspect yours has hyper-threading too, since Linux mentions
  that it sees an ACPI SMP table, but usually, hyper-threading needs to be
  enabled at BIOS level.
 
  
  yes, it has ht. disabled now. i thought that i don't want to try to
  solve superposition of various corner cases and stuck on solving this.
  
  otoh, i could create such case. did i ?
  
  (btw, rtai 3.7 works)
 
 This does not give us any clue, since neither the I-pipe patch nor the
 heap code are shared. 

yes, i could not mention it.


 But as I said, I suspect the bug is rather in the
 kernel configuration than anywhere else.

i see.

 
 We are going to try something else. The .config I use on my atom is here:
 http://git.xenomai.org/?p=mkrootfs.git;a=blob_plain;f=boards/generic/atom-32/config-2.6.31;hb=HEAD
 
 Could you start from this configuration, adding only what is needed to
 boot your box (root filesystem device controller, or network controller
 if booting over nfs, root filesystem), then test this kernel?
 

yes. i downloaded this config a while ago. need to setup new kernel
2.6.31.1 with xenomai. 
is 2.5.4 suitable for this test ? 
should i also use adeos-*.31.1-*2.4-09 patch ?



-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 yes. i downloaded this config a while ago. need to setup new kernel
 2.6.31.1 with xenomai. 
 is 2.5.4 suitable for this test ? 
 should i also use adeos-*.31.1-*2.4-09 patch ?

See the versions I posted in my test report yesterday. They were made
with this configuration.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
 
 See the versions I posted in my test report yesterday. They were made
 with this configuration.
 

ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,

for xenomai's configure i will pass following switches:
--enable-x86-sep --enable-x86-tsc --enable-smp

is this okay ?


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 yes. i downloaded this config a while ago. need to setup new kernel
 2.6.31.1 with xenomai. 
 is 2.5.4 suitable for this test ? 
 should i also use adeos-*.31.1-*2.4-09 patch ?
 See the versions I posted in my test report yesterday. They were made
 with this configuration.

 
 ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
 
 for xenomai's configure i will pass following switches:
 --enable-x86-sep --enable-x86-tsc --enable-smp
 
 is this okay ?

Yes.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
  See the versions I posted in my test report yesterday. They were made
  with this configuration.
 
  
  ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
  
  for xenomai's configure i will pass following switches:
  --enable-x86-sep --enable-x86-tsc --enable-smp
  
  is this okay ?
 
 Yes.
 

bingo !

atest:~/xeno-test-254-2 # ./.try.sh 
main:79 heap 0x401b1000
/root/xeno-test-254-2
main:96 [823] pid 825
main:89
main:90 [825] pid 0
main:99 [823] pid 825, status 0b00
main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
0
atest:~/xeno-test-254-2 # uname -a
Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
i686 i686 i386 GNU/Linux


my fork() test works now with kernel configured with your config.

so this try proves no doubt that userland (libc, pthreads and so on)
work.

and i guess that this memory corruption which caused fork to die inside
libc can be something specific to UP configuration. (i was thinking
about using my config with smp this time)

Thank you for sending me kernel configuration which pointed out an area
which should be searched further.

Regards,

-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 yes. i downloaded this config a while ago. need to setup new kernel
 2.6.31.1 with xenomai. 
 is 2.5.4 suitable for this test ? 
 should i also use adeos-*.31.1-*2.4-09 patch ?
 See the versions I posted in my test report yesterday. They were made
 with this configuration.

 ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,

 for xenomai's configure i will pass following switches:
 --enable-x86-sep --enable-x86-tsc --enable-smp

 is this okay ?
 Yes.

 
 bingo !
 
 atest:~/xeno-test-254-2 # ./.try.sh 
 main:79 heap 0x401b1000
 /root/xeno-test-254-2
 main:96 [823] pid 825
 main:89
 main:90 [825] pid 0
 main:99 [823] pid 825, status 0b00
 main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
 0
 atest:~/xeno-test-254-2 # uname -a
 Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
 i686 i686 i386 GNU/Linux
 
 
 my fork() test works now with kernel configured with your config.
 
 so this try proves no doubt that userland (libc, pthreads and so on)
 work.
 
 and i guess that this memory corruption which caused fork to die inside
 libc can be something specific to UP configuration. (i was thinking
 about using my config with smp this time)
 
 Thank you for sending me kernel configuration which pointed out an area
 which should be searched further.

Yes, now if you find the culprit option, it would be nice to report here
so that we can fix the I-pipe patch.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
  See the versions I posted in my test report yesterday. They were made
  with this configuration.
 
  
  ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
  
  for xenomai's configure i will pass following switches:
  --enable-x86-sep --enable-x86-tsc --enable-smp
  
  is this okay ?
 
 Yes.
 

and of course this issue doesn't happen because native kernel was
strange configured.

when i used non-rt xeno-shmem-fork (without calls to heap routines) it
worked well on that misconfigured kernel too.

this must be caused by some missed bit in Xenomai (and/or adeos patch)


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 17:13 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
  See the versions I posted in my test report yesterday. They were made
  with this configuration.
 
  ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
 
  for xenomai's configure i will pass following switches:
  --enable-x86-sep --enable-x86-tsc --enable-smp
 
  is this okay ?
  Yes.
 
  
  bingo !
  
  atest:~/xeno-test-254-2 # ./.try.sh 
  main:79 heap 0x401b1000
  /root/xeno-test-254-2
  main:96 [823] pid 825
  main:89
  main:90 [825] pid 0
  main:99 [823] pid 825, status 0b00
  main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
  0
  atest:~/xeno-test-254-2 # uname -a
  Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
  i686 i686 i386 GNU/Linux
  
  
  my fork() test works now with kernel configured with your config.
  
  so this try proves no doubt that userland (libc, pthreads and so on)
  work.
  
  and i guess that this memory corruption which caused fork to die inside
  libc can be something specific to UP configuration. (i was thinking
  about using my config with smp this time)
  
  Thank you for sending me kernel configuration which pointed out an area
  which should be searched further.
 
 Yes, now if you find the culprit option, it would be nice to report here
 so that we can fix the I-pipe patch.
 

okay. will try to dig up.


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 17:13 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 yes. i downloaded this config a while ago. need to setup new kernel
 2.6.31.1 with xenomai. 
 is 2.5.4 suitable for this test ? 
 should i also use adeos-*.31.1-*2.4-09 patch ?
 See the versions I posted in my test report yesterday. They were made
 with this configuration.

 ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,

 for xenomai's configure i will pass following switches:
 --enable-x86-sep --enable-x86-tsc --enable-smp

 is this okay ?
 Yes.

 bingo !

 atest:~/xeno-test-254-2 # ./.try.sh 
 main:79 heap 0x401b1000
 /root/xeno-test-254-2
 main:96 [823] pid 825
 main:89
 main:90 [825] pid 0
 main:99 [823] pid 825, status 0b00
 main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
 0
 atest:~/xeno-test-254-2 # uname -a
 Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
 i686 i686 i386 GNU/Linux


 my fork() test works now with kernel configured with your config.

 so this try proves no doubt that userland (libc, pthreads and so on)
 work.

 and i guess that this memory corruption which caused fork to die inside
 libc can be something specific to UP configuration. (i was thinking
 about using my config with smp this time)

 Thank you for sending me kernel configuration which pointed out an area
 which should be searched further.
 Yes, now if you find the culprit option, it would be nice to report here
 so that we can fix the I-pipe patch.

 
 okay. will try to dig up.

As a first quick test, could you try and disable CONFIG_AUDITSYSCALL ?

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 17:43 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 17:13 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
  See the versions I posted in my test report yesterday. They were made
  with this configuration.
 
  ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
 
  for xenomai's configure i will pass following switches:
  --enable-x86-sep --enable-x86-tsc --enable-smp
 
  is this okay ?
  Yes.
 
  bingo !
 
  atest:~/xeno-test-254-2 # ./.try.sh 
  main:79 heap 0x401b1000
  /root/xeno-test-254-2
  main:96 [823] pid 825
  main:89
  main:90 [825] pid 0
  main:99 [823] pid 825, status 0b00
  main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
  0
  atest:~/xeno-test-254-2 # uname -a
  Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
  i686 i686 i386 GNU/Linux
 
 
  my fork() test works now with kernel configured with your config.
 
  so this try proves no doubt that userland (libc, pthreads and so on)
  work.
 
  and i guess that this memory corruption which caused fork to die inside
  libc can be something specific to UP configuration. (i was thinking
  about using my config with smp this time)
 
  Thank you for sending me kernel configuration which pointed out an area
  which should be searched further.
  Yes, now if you find the culprit option, it would be nice to report here
  so that we can fix the I-pipe patch.
 
  
  okay. will try to dig up.
 
 As a first quick test, could you try and disable CONFIG_AUDITSYSCALL ?

okay. i have tried so far smp + ht but it didn't change anything.


 


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 17:43 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 17:13 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
  See the versions I posted in my test report yesterday. They were made
  with this configuration.
 
  ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
 
  for xenomai's configure i will pass following switches:
  --enable-x86-sep --enable-x86-tsc --enable-smp
 
  is this okay ?
  Yes.
 
  bingo !
 
  atest:~/xeno-test-254-2 # ./.try.sh 
  main:79 heap 0x401b1000
  /root/xeno-test-254-2
  main:96 [823] pid 825
  main:89
  main:90 [825] pid 0
  main:99 [823] pid 825, status 0b00
  main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
  0
  atest:~/xeno-test-254-2 # uname -a
  Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
  i686 i686 i386 GNU/Linux
 
 
  my fork() test works now with kernel configured with your config.
 
  so this try proves no doubt that userland (libc, pthreads and so on)
  work.
 
  and i guess that this memory corruption which caused fork to die inside
  libc can be something specific to UP configuration. (i was thinking
  about using my config with smp this time)
 
  Thank you for sending me kernel configuration which pointed out an area
  which should be searched further.
  Yes, now if you find the culprit option, it would be nice to report here
  so that we can fix the I-pipe patch.
 
  
  okay. will try to dig up.
 
 As a first quick test, could you try and disable CONFIG_AUDITSYSCALL ?
 


seems that without auditsyscall fork dies too.

-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-18 Thread Krzysztof Błaszkowski
On Wed, 2010-08-18 at 17:43 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 17:13 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:30 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Wed, 2010-08-18 at 16:10 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  yes. i downloaded this config a while ago. need to setup new kernel
  2.6.31.1 with xenomai. 
  is 2.5.4 suitable for this test ? 
  should i also use adeos-*.31.1-*2.4-09 patch ?
  See the versions I posted in my test report yesterday. They were made
  with this configuration.
 
  ok. kernel 2.6.31.8, 2.5.4, ht will be enabled,
 
  for xenomai's configure i will pass following switches:
  --enable-x86-sep --enable-x86-tsc --enable-smp
 
  is this okay ?
  Yes.
 
  bingo !
 
  atest:~/xeno-test-254-2 # ./.try.sh 
  main:79 heap 0x401b1000
  /root/xeno-test-254-2
  main:96 [823] pid 825
  main:89
  main:90 [825] pid 0
  main:99 [823] pid 825, status 0b00
  main:100 [823] pid 825, WIFSIGNALED 0, WIFEXITED 1, rc 11
  0
  atest:~/xeno-test-254-2 # uname -a
  Linux atest 2.6.31.8-xeno254-smp-ht #1 SMP Wed Aug 18 17:04:00 CEST 2010
  i686 i686 i386 GNU/Linux
 
 
  my fork() test works now with kernel configured with your config.
 
  so this try proves no doubt that userland (libc, pthreads and so on)
  work.
 
  and i guess that this memory corruption which caused fork to die inside
  libc can be something specific to UP configuration. (i was thinking
  about using my config with smp this time)
 
  Thank you for sending me kernel configuration which pointed out an area
  which should be searched further.
  Yes, now if you find the culprit option, it would be nice to report here
  so that we can fix the I-pipe patch.
 
  
  okay. will try to dig up.
 
 As a first quick test, could you try and disable CONFIG_AUDITSYSCALL ?
 

whole CONFIG_AUDIT disabled and SELINUX too. fork test fails still.


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 Hello,
 
 I found recently that large application uses to segfault before fork()
 leaves its glibc wrapper.
 
 I included here a test suite which can be easily used to verify what
 goes wrong. It may be necessary to adjust makefile to compile the code.
 So, the console is missing output from line #89. We can see instead a
 message that getpid couldn't be linked which is 1st sign of memory
 corruption.
 
 i used to think that this issue could be related to not unbinding heap
 before fork() but it turned out that it is enough to link userspace with
 xenomai libraries.
 
 I wonder if this is known issue and if there is any fix, does 2.5.4 work
 same ? or maybe there is something wrong with the kernel i use (or adeos
 patch)
 
 Another question is why rt_task_create() is marked deprecated in native
 skin. Does it mean that native skin is going to be removed from source
 tree ?

The libc on the system you run the test is not the same as the one of
the compiler. Please re-run the test when using the same libc on the
test board as on the machine where you are compiling.


-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
On Tue, 2010-08-17 at 14:33 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  Hello,
  
  I found recently that large application uses to segfault before fork()
  leaves its glibc wrapper.
  
  I included here a test suite which can be easily used to verify what
  goes wrong. It may be necessary to adjust makefile to compile the code.
  So, the console is missing output from line #89. We can see instead a
  message that getpid couldn't be linked which is 1st sign of memory
  corruption.
  
  i used to think that this issue could be related to not unbinding heap
  before fork() but it turned out that it is enough to link userspace with
  xenomai libraries.
  
  I wonder if this is known issue and if there is any fix, does 2.5.4 work
  same ? or maybe there is something wrong with the kernel i use (or adeos
  patch)
  
  Another question is why rt_task_create() is marked deprecated in native
  skin. Does it mean that native skin is going to be removed from source
  tree ?
 
 The libc on the system you run the test is not the same as the one of
 the compiler. Please re-run the test when using the same libc on the
 test board as on the machine where you are compiling.


I reckon you missed the clue. On the other hand: how can you explain
that main process even started ? and only child failed ?

and indeed i compile code on one box but run on another anyway both
rootfs'es are bit equal.

 
 


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
On Tue, 2010-08-17 at 14:33 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  Hello,
  
  I found recently that large application uses to segfault before fork()
  leaves its glibc wrapper.
  
  I included here a test suite which can be easily used to verify what
  goes wrong. It may be necessary to adjust makefile to compile the code.
  So, the console is missing output from line #89. We can see instead a
  message that getpid couldn't be linked which is 1st sign of memory
  corruption.
  
  i used to think that this issue could be related to not unbinding heap
  before fork() but it turned out that it is enough to link userspace with
  xenomai libraries.
  
  I wonder if this is known issue and if there is any fix, does 2.5.4 work
  same ? or maybe there is something wrong with the kernel i use (or adeos
  patch)
  
  Another question is why rt_task_create() is marked deprecated in native
  skin. Does it mean that native skin is going to be removed from source
  tree ?
 
 The libc on the system you run the test is not the same as the one of
 the compiler. Please re-run the test when using the same libc on the
 test board as on the machine where you are compiling.
 

these rootfs'es are equal regarding libc at least of course.

 


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Tue, 2010-08-17 at 14:33 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 Hello,

 I found recently that large application uses to segfault before fork()
 leaves its glibc wrapper.

 I included here a test suite which can be easily used to verify what
 goes wrong. It may be necessary to adjust makefile to compile the code.
 So, the console is missing output from line #89. We can see instead a
 message that getpid couldn't be linked which is 1st sign of memory
 corruption.

 i used to think that this issue could be related to not unbinding heap
 before fork() but it turned out that it is enough to link userspace with
 xenomai libraries.

 I wonder if this is known issue and if there is any fix, does 2.5.4 work
 same ? or maybe there is something wrong with the kernel i use (or adeos
 patch)

 Another question is why rt_task_create() is marked deprecated in native
 skin. Does it mean that native skin is going to be removed from source
 tree ?
 The libc on the system you run the test is not the same as the one of
 the compiler. Please re-run the test when using the same libc on the
 test board as on the machine where you are compiling.
 
 
 I reckon you missed the clue. On the other hand: how can you explain
 that main process even started ? and only child failed ?
 
 and indeed i compile code on one box but run on another anyway both
 rootfs'es are bit equal.

No. As witnessed by the message:
./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid,
version GLIBC_2.0 not defined in file libc.so.6 with link time reference

The run-time glibc is not the same as the compile-time glibc. The glibc
are mostly ABI compatible, but maybe not the fork wrapper, so, to rule
this out, please re-run the test with the correct glibc.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Tue, 2010-08-17 at 14:33 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 Hello,

 I found recently that large application uses to segfault before fork()
 leaves its glibc wrapper.

 I included here a test suite which can be easily used to verify what
 goes wrong. It may be necessary to adjust makefile to compile the code.
 So, the console is missing output from line #89. We can see instead a
 message that getpid couldn't be linked which is 1st sign of memory
 corruption.

 i used to think that this issue could be related to not unbinding heap
 before fork() but it turned out that it is enough to link userspace with
 xenomai libraries.

 I wonder if this is known issue and if there is any fix, does 2.5.4 work
 same ? or maybe there is something wrong with the kernel i use (or adeos
 patch)

 Another question is why rt_task_create() is marked deprecated in native
 skin. Does it mean that native skin is going to be removed from source
 tree ?
 The libc on the system you run the test is not the same as the one of
 the compiler. Please re-run the test when using the same libc on the
 test board as on the machine where you are compiling.

 
 these rootfs'es are equal regarding libc at least of course.

It is not a matter of rootfs glibc, but rather a problem of compiler
glibc versus rootfs glibc.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
On Tue, 2010-08-17 at 14:40 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Tue, 2010-08-17 at 14:33 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  Hello,
 
  I found recently that large application uses to segfault before fork()
  leaves its glibc wrapper.
 
  I included here a test suite which can be easily used to verify what
  goes wrong. It may be necessary to adjust makefile to compile the code.
  So, the console is missing output from line #89. We can see instead a
  message that getpid couldn't be linked which is 1st sign of memory
  corruption.
 
  i used to think that this issue could be related to not unbinding heap
  before fork() but it turned out that it is enough to link userspace with
  xenomai libraries.
 
  I wonder if this is known issue and if there is any fix, does 2.5.4 work
  same ? or maybe there is something wrong with the kernel i use (or adeos
  patch)
 
  Another question is why rt_task_create() is marked deprecated in native
  skin. Does it mean that native skin is going to be removed from source
  tree ?
  The libc on the system you run the test is not the same as the one of
  the compiler. Please re-run the test when using the same libc on the
  test board as on the machine where you are compiling.
  
  
  I reckon you missed the clue. On the other hand: how can you explain
  that main process even started ? and only child failed ?
  
  and indeed i compile code on one box but run on another anyway both
  rootfs'es are bit equal.
 
 No. As witnessed by the message:
 ./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid,
 version GLIBC_2.0 not defined in file libc.so.6 with link time reference


have you seen that main process started  ? and linker didn't complain
about wrong symbol version. This happened only in child process after
line 88, have you seen output from line 89 ?

furthermore you can find commented out line in makefile which compiles
userland without linking with xenomai libraries. 

this executable works as expected.

 
 The run-time glibc is not the same as the compile-time glibc. The glibc
 are mostly ABI compatible, but maybe not the fork wrapper, so, to rule
 this out, please re-run the test with the correct glibc.
 

this is from libc on box i compile code:
GNU C Library stable release version 2.9 (20081117), by Roland McGrath
et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 4.3.2 [gcc-4_3-branch revision 141291].
Compiled on a Linux 2.6.27 system on 2008-12-03.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
NoVersion patch for broken glibc 2.0 binaries
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
CHroot linux-e9um:/lib # 



and this is from target box:
atest:/lib # ./libc-2.9.so
GNU C Library stable release version 2.9 (20081117), by Roland McGrath
et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 4.3.2 [gcc-4_3-branch revision 141291].
Compiled on a Linux 2.6.27 system on 2008-12-03.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
NoVersion patch for broken glibc 2.0 binaries
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
atest:/lib #  



these libcs are same and i wonder whats wrong with you. 
How many times do i need to make you sure that these libcs are binary
same ?







-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Tue, 2010-08-17 at 14:40 +0200, Gilles Chanteperdrix wrote:
 No. As witnessed by the message:
 ./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid,
 version GLIBC_2.0 not defined in file libc.so.6 with link time reference
 
 
 have you seen that main process started  ? and linker didn't complain
 about wrong symbol version. This happened only in child process after
 line 88, have you seen output from line 89 ?
 
 furthermore you can find commented out line in makefile which compiles
 userland without linking with xenomai libraries. 
 
 this executable works as expected.

As I said since we went from libc5 to libc6, all libcs have been
backward ABI compatible. So, it makes perfect sense that the binary works.

Since you are calling getpid() after fork, it is normal that the error
is not signalled before, symbols are only resolved at run-time, when
they are use.

 these libcs are same and i wonder whats wrong with you. 
 How many times do i need to make you sure that these libcs are binary
 same ?

As long as you are comparing the wrong binaries. What I ask you to
compare is libc.so.6 with the result of gcc -print-file-name=libc.so
gcc being the exact compiler use for compilation of the test program.

If these libraries are the same, then I will look at your test program,
otherwise I will not waste more time on this issue.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
On Tue, 2010-08-17 at 15:06 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Tue, 2010-08-17 at 14:40 +0200, Gilles Chanteperdrix wrote:
  No. As witnessed by the message:
  ./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid,
  version GLIBC_2.0 not defined in file libc.so.6 with link time reference
  
  
  have you seen that main process started  ? and linker didn't complain
  about wrong symbol version. This happened only in child process after
  line 88, have you seen output from line 89 ?
  
  furthermore you can find commented out line in makefile which compiles
  userland without linking with xenomai libraries. 
  
  this executable works as expected.
 
 As I said since we went from libc5 to libc6, all libcs have been
 backward ABI compatible. So, it makes perfect sense that the binary works.
 
 Since you are calling getpid() after fork, it is normal that the error
 is not signalled before, symbols are only resolved at run-time, when
 they are use.

indeed so i think you should ask yourself how it was possible that main
process could resolve it but child couldn't.

 
  these libcs are same and i wonder whats wrong with you. 
  How many times do i need to make you sure that these libcs are binary
  same ?
 
 As long as you are comparing the wrong binaries. What I ask you to
 compare is libc.so.6 with the result of gcc -print-file-name=libc.so
 gcc being the exact compiler use for compilation of the test program.
 
 If these libraries are the same, then I will look at your test program,
 otherwise I will not waste more time on this issue.

so at the box i compile code gcc gives:
CHroot linux-e9um:/lib # gcc -print-file-name=libc.so
/usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so


and i do not have gcc installed at target box (atest). i also double
checked if there could be libc.so file in whole rootfs which is abt
258M long and i did not found it.

also /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so
ie /usr/lib/libc.so is just a linker script of 238 bytes.

ld-linux.so.2 are binary same on these two boxes too.


 


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Tue, 2010-08-17 at 15:06 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
 On Tue, 2010-08-17 at 14:40 +0200, Gilles Chanteperdrix wrote:
 No. As witnessed by the message:
 ./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid,
 version GLIBC_2.0 not defined in file libc.so.6 with link time reference

 have you seen that main process started  ? and linker didn't complain
 about wrong symbol version. This happened only in child process after
 line 88, have you seen output from line 89 ?

 furthermore you can find commented out line in makefile which compiles
 userland without linking with xenomai libraries. 

 this executable works as expected.
 As I said since we went from libc5 to libc6, all libcs have been
 backward ABI compatible. So, it makes perfect sense that the binary works.

 Since you are calling getpid() after fork, it is normal that the error
 is not signalled before, symbols are only resolved at run-time, when
 they are use.
 
 indeed so i think you should ask yourself how it was possible that main
 process could resolve it but child couldn't.

That is easy to answer: only the child calls getpid().

 
 these libcs are same and i wonder whats wrong with you. 
 How many times do i need to make you sure that these libcs are binary
 same ?
 As long as you are comparing the wrong binaries. What I ask you to
 compare is libc.so.6 with the result of gcc -print-file-name=libc.so
 gcc being the exact compiler use for compilation of the test program.

 If these libraries are the same, then I will look at your test program,
 otherwise I will not waste more time on this issue.
 
 so at the box i compile code gcc gives:
 CHroot linux-e9um:/lib # gcc -print-file-name=libc.so
 /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so
 
 
 and i do not have gcc installed at target box (atest). i also double
 checked if there could be libc.so file in whole rootfs which is abt
 258M long and i did not found it.
 
 also /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so
 ie /usr/lib/libc.so is just a linker script of 238 bytes.
 
 ld-linux.so.2 are binary same on these two boxes too.

What are the contents of this linker script? I did not ask to compare
gcc -print-file-name=libc.so with the same file on the target. I asked
to compare:
gcc -print-file-name=libc.so (or if it is a linker script, the libc.so.6
it references)
with  /lib/libc.so.6

In other words: the libc used by the compiler with the libc used at
run-time, as my very first answer was asking.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
On Tue, 2010-08-17 at 15:27 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Tue, 2010-08-17 at 15:06 +0200, Gilles Chanteperdrix wrote:
  Krzysztof Błaszkowski wrote:
  On Tue, 2010-08-17 at 14:40 +0200, Gilles Chanteperdrix wrote:
  No. As witnessed by the message:
  ./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid,
  version GLIBC_2.0 not defined in file libc.so.6 with link time reference
 
  have you seen that main process started  ? and linker didn't complain
  about wrong symbol version. This happened only in child process after
  line 88, have you seen output from line 89 ?
 
  furthermore you can find commented out line in makefile which compiles
  userland without linking with xenomai libraries. 
 
  this executable works as expected.
  As I said since we went from libc5 to libc6, all libcs have been
  backward ABI compatible. So, it makes perfect sense that the binary works.
 
  Since you are calling getpid() after fork, it is normal that the error
  is not signalled before, symbols are only resolved at run-time, when
  they are use.
  
  indeed so i think you should ask yourself how it was possible that main
  process could resolve it but child couldn't.
 
 That is easy to answer: only the child calls getpid().

;) not only. see the short code.

 
  
  these libcs are same and i wonder whats wrong with you. 
  How many times do i need to make you sure that these libcs are binary
  same ?
  As long as you are comparing the wrong binaries. What I ask you to
  compare is libc.so.6 with the result of gcc -print-file-name=libc.so
  gcc being the exact compiler use for compilation of the test program.
 
  If these libraries are the same, then I will look at your test program,
  otherwise I will not waste more time on this issue.
  
  so at the box i compile code gcc gives:
  CHroot linux-e9um:/lib # gcc -print-file-name=libc.so
  /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so
  
  
  and i do not have gcc installed at target box (atest). i also double
  checked if there could be libc.so file in whole rootfs which is abt
  258M long and i did not found it.
  
  also /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so
  ie /usr/lib/libc.so is just a linker script of 238 bytes.
  
  ld-linux.so.2 are binary same on these two boxes too.
 
 What are the contents of this linker script? I did not ask to compare
 gcc -print-file-name=libc.so with the same file on the target. I asked
 to compare:
 gcc -print-file-name=libc.so (or if it is a linker script, the libc.so.6
 it references)
 with  /lib/libc.so.6
 
 In other words: the libc used by the compiler with the libc used at
 run-time, as my very first answer was asking.
 

/usr/lib/libc.so can't be compared with /lib/libc.so.6.

i included libc.so from /usr for reference.






-- 
Krzysztof Blaszkowski


libc.so
Description: application/sharedlib
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 On Tue, 2010-08-17 at 15:27 +0200, Gilles Chanteperdrix wrote:
 What are the contents of this linker script? I did not ask to compare
 gcc -print-file-name=libc.so with the same file on the target. I asked
 to compare:
 gcc -print-file-name=libc.so (or if it is a linker script, the libc.so.6
 it references)
 with  /lib/libc.so.6

 In other words: the libc used by the compiler with the libc used at
 run-time, as my very first answer was asking.

 
 /usr/lib/libc.so can't be compared with /lib/libc.so.6.

libc.so is a linker script, so the sentence or if it is a linker
script, the libc.so.6 it references applies.

Anyway, now we got to the bottom of it, ok, libc.so references
/lib/libc.so.6. But since you already made me spend one hour having you
understand the difference between the compiler libc and the one of the
root filesystem, I will not have be able to run your test before tonight.

In the mean-time, please run your test with Xenomai 2.5.4.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
On Tue, 2010-08-17 at 16:08 +0200, Gilles Chanteperdrix wrote:
 Krzysztof Błaszkowski wrote:
  On Tue, 2010-08-17 at 15:27 +0200, Gilles Chanteperdrix wrote:
  What are the contents of this linker script? I did not ask to compare
  gcc -print-file-name=libc.so with the same file on the target. I asked
  to compare:
  gcc -print-file-name=libc.so (or if it is a linker script, the libc.so.6
  it references)
  with  /lib/libc.so.6
 
  In other words: the libc used by the compiler with the libc used at
  run-time, as my very first answer was asking.
 
  
  /usr/lib/libc.so can't be compared with /lib/libc.so.6.
 
 libc.so is a linker script, so the sentence or if it is a linker
 script, the libc.so.6 it references applies.
 
 Anyway, now we got to the bottom of it, ok, libc.so references
 /lib/libc.so.6. But since you already made me spend one hour having you
 understand the difference between the compiler libc and the one of the
 root filesystem, I will not have be able to run your test before tonight.

well, you were not precise enough neither i was not aware enough of gcc
kitchen.

i see. thanks.

 
 In the mean-time, please run your test with Xenomai 2.5.4.
 

will try to setup everything. it may take an hour too.

i can guess that it will fail too because i have an impression that this
issue confused you, so it is highly possible that the issue has not been
solved yet.



-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 In the mean-time, please run your test with Xenomai 2.5.4.

 
 will try to setup everything. it may take an hour too.
 
 i can guess that it will fail too because i have an impression that this
 issue confused you, so it is highly possible that the issue has not been
 solved yet.

Philippe has made a series of cleanups in rt_heaps for 2.5.4, as far as
I remember, it was only for processors without MMU, but maybe not.

-- 
Gilles.


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Philippe Gerum
On Tue, 2010-08-17 at 14:25 +0200, Krzysztof Błaszkowski wrote:
 Hello,
 
 I found recently that large application uses to segfault before fork()
 leaves its glibc wrapper.
 
 I included here a test suite which can be easily used to verify what
 goes wrong. It may be necessary to adjust makefile to compile the code.
 So, the console is missing output from line #89. We can see instead a
 message that getpid couldn't be linked which is 1st sign of memory
 corruption.
 
 i used to think that this issue could be related to not unbinding heap
 before fork() but it turned out that it is enough to link userspace with
 xenomai libraries.
 
 I wonder if this is known issue and if there is any fix, does 2.5.4 work
 same ? or maybe there is something wrong with the kernel i use (or adeos
 patch)
 
 Another question is why rt_task_create() is marked deprecated in native
 skin.

rt_task_create() as defined by the kernel-side API is marked as
deprecated. The user-space version of rt_task_create() is not.

  Does it mean that native skin is going to be removed from source
 tree ?
 

No. It means that starting with the next major evolution of Xenomai
(i.e. 3.x), skins will no more export any kernel-based API (except
RTDM). In short, if your application is running in user-space, nothing
will change for you. OTOH, applications currently running in kernel
space over the native API should consider moving to user-space at some
point, because we won't support the former programming model
indefinitely. The rationale for this decision is explained here:
http://www.xenomai.org/index.php/Xenomai:Roadmap#What_Will_Change_With_Xenomai_3

The keyword here is application, obviously not drivers, which are by
essence better supported in kernel space in the Linux environment, and
Xenomai 3.x will keep on providing what is required to develop them
there over RTDM.

 Regards,
 
 ___
 Xenomai-core mailing list
 Xenomai-core@gna.org
 https://mail.gna.org/listinfo/xenomai-core

-- 
Philippe.



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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Krzysztof Błaszkowski
Hi Philippe,

On Tue, 2010-08-17 at 16:41 +0200, Philippe Gerum wrote:
 On Tue, 2010-08-17 at 14:25 +0200, Krzysztof Błaszkowski wrote:
  Hello,
  
  I found recently that large application uses to segfault before fork()
  leaves its glibc wrapper.
  
  I included here a test suite which can be easily used to verify what
  goes wrong. It may be necessary to adjust makefile to compile the code.
  So, the console is missing output from line #89. We can see instead a
  message that getpid couldn't be linked which is 1st sign of memory
  corruption.
  
  i used to think that this issue could be related to not unbinding heap
  before fork() but it turned out that it is enough to link userspace with
  xenomai libraries.
  
  I wonder if this is known issue and if there is any fix, does 2.5.4 work
  same ? or maybe there is something wrong with the kernel i use (or adeos
  patch)
  
  Another question is why rt_task_create() is marked deprecated in native
  skin.
 
 rt_task_create() as defined by the kernel-side API is marked as
 deprecated. The user-space version of rt_task_create() is not.
 
   Does it mean that native skin is going to be removed from source
  tree ?
  
 
 No. It means that starting with the next major evolution of Xenomai
 (i.e. 3.x), skins will no more export any kernel-based API (except
 RTDM). In short, if your application is running in user-space, nothing
 will change for you. OTOH, applications currently running in kernel
 space over the native API should consider moving to user-space at some
 point, because we won't support the former programming model
 indefinitely. The rationale for this decision is explained here:
 http://www.xenomai.org/index.php/Xenomai:Roadmap#What_Will_Change_With_Xenomai_3
 
 The keyword here is application, obviously not drivers, which are by
 essence better supported in kernel space in the Linux environment, and
 Xenomai 3.x will keep on providing what is required to develop them
 there over RTDM.


Thank you for explanation. it means to me lots of work in the future if
i wanted to be up-to-date with mainstream development.
I am glad to see that Xeonami II is going to be maintained for long
time.

Regards,

 
  Regards,
  
  ___
  Xenomai-core mailing list
  Xenomai-core@gna.org
  https://mail.gna.org/listinfo/xenomai-core
 


-- 
Krzysztof Blaszkowski


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


Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

2010-08-17 Thread Gilles Chanteperdrix
Krzysztof Błaszkowski wrote:
 Hello,
 
 I found recently that large application uses to segfault before fork()
 leaves its glibc wrapper.
 
 I included here a test suite which can be easily used to verify what
 goes wrong. It may be necessary to adjust makefile to compile the code.
 So, the console is missing output from line #89. We can see instead a
 message that getpid couldn't be linked which is 1st sign of memory
 corruption.
 
 i used to think that this issue could be related to not unbinding heap
 before fork() but it turned out that it is enough to link userspace with
 xenomai libraries.
 
 I wonder if this is known issue and if there is any fix, does 2.5.4 work
 same ? or maybe there is something wrong with the kernel i use (or adeos
 patch)
 
 Another question is why rt_task_create() is marked deprecated in native
 skin. Does it mean that native skin is going to be removed from source
 tree ?

Ok. Tried your test on:
- 2.6.33 armv5
- 2.6.34 x86_64
- 2.6.31 x86_64
- 2.6.31 x86_32

And everything works fine.

The result of the last experience is:
# xeno-shmem-fork
main:43 heap 0xb76be000
/root
main:60 [4365] pid 4367
main:53
main:54 [4367] pid 0
main:63 [4365] pid 4367, status 0b00
main:64 [4365] pid 4367, WIFSIGNALED 0, WIFEXITED 1, rc 11
0
# cat /proc/ipipe/version
2.4-09
# cat /proc/xenomai/version
2.5.4
# uname -a
Linux atom 2.6.31.8 #5 SMP Wed Aug 18 00:44:17 CEST 2010 i686 GNU/Linux

There does not seem to be anything wrong in xenomai rt_heap code, as
this code is platform-independent, so if there was something wrong with
it, we would see it on all platforms.

Some clues about what could be wrong:
- I am not sure your makefile works: the .o file has the same name for
the kernel module and the executable. I do not think this could matter
(if you could get it wrong, the module or the executable would not run),
but in any case, this is a bad idea, and since the kernel module and
user-space application do not share any code, it seems simpler to put
them in separate files.
- I have not really checked your user-space compilation flags, I am
using xeno-config to get the correct ones.
- your user-space code was missing #include unistd.h
- some subtle difference in the glibc
- some x86_32 specific I-pipe bug triggered by some kernel configuration
option
- some local patches in your kernel

In any case, without further information, it is hard for me to dig any
further tonight. Regards.

-- 
Gilles.


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