Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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()
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
