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

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

[Krzysztof Błaszkowski]

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

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 ?

Regards,

-- 
Krzysztof Blaszkowski

[-- Attachment #2: .try.sh --]
[-- Type: application/x-shellscript, Size: 114 bytes --]

[-- Attachment #3: console.log --]
[-- Type: text/x-log, Size: 368 bytes --]

atest:~/xeno-test # ./.try.sh
main:78 heap 0x401be000
/root/xeno-test
main:88
./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
main:95 [2234] pid 2236
main:98 [2234] pid 2236, status 00007f00
main:99 [2234] pid 2236, WIFSIGNALED 0, WIFEXITED 1, rc 127
4
atest:~/xeno-test #

[-- Attachment #4: Makefile --]
[-- Type: text/x-makefile, Size: 690 bytes --]


export KERNELDIR ?= $(shell pwd)/../kernel
XENODIR = $(KERNELDIR)/INSTALL/xeno/usr/xenomai


obj-m = xeno_shmem_test.o
xeno_shmem_test-objs = xeno-shmem-fork.o

EXTRA_CFLAGS = -I$(XENODIR)/include
U_LDFLAGS = -lnative -lxenomai -L$(XENODIR)/lib -D_XENO_SHMEM_

all: xmodule userland

xmodule: xeno-shmem-fork.c
	$(MAKE) -C $(KERNELDIR) SUBDIRS=`pwd` V=0 -o $(KERNELDIR)/Module.symvers modules 
	
userland: xeno-shmem-fork.c
	gcc xeno-shmem-fork.c $(EXTRA_CFLAGS) $(U_LDFLAGS) -o xeno-shmem-fork
#	gcc xeno-shmem-fork.c $(EXTRA_CFLAGS)  -o xeno-shmem-fork
	

give-a-try:
	insmod ./xeno_shmem_test.ko
	sleep .1
	LD_LIBRARY_PATH=`pwd` ./xeno-shmem-fork
	sleep .1
	rmmod xeno_shmem_test
	





[-- Attachment #5: xeno-shmem-fork.c --]
[-- Type: text/x-csrc, Size: 2362 bytes --]

/* xenomai/native - fork() regression test
    Systemy mikroprocesorowe 2010
*/


#include <native/heap.h>


#define TEST_HEAP "0x12345"

#ifdef __KERNEL__
#include <linux/module.h>

MODULE_LICENSE("GPL");

#define HEAP_SIZE (16*1024)

RT_HEAP heap_desc;
void *ptr;

int init(void)
{
    int err;

    err = rt_heap_create(&heap_desc, TEST_HEAP , HEAP_SIZE, H_SHARED);
    if (!err) {
	    err = rt_heap_alloc(&heap_desc, 0, TM_NONBLOCK, &ptr);
    }
    
    printk("%s:%d heap %p, rc %d\n", __FUNCTION__, __LINE__, ptr, err);

    return err;
}

void exit(void)
{
    printk("%s:%d heap %p\n", __FUNCTION__, __LINE__, ptr);
    rt_heap_delete(&heap_desc);
}

module_init(init);
module_exit(exit);


#else

#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

RT_HEAP heap_desc;

void *shared_mem; /* Start address of the shared memory segment */

/* A shared memory segment with Xenomai is implemented as a mappable
   real-time heap object managed as a single memory block. In this
   mode, the allocation routine always returns the start address of
   the heap memory to all callers, and the free routine always leads
   to a no-op. */

#define EXIT_RC 11
int main (int argc, char *argv[])

{
    int err;
    int pid;

#ifdef _XENO_SHMEM_
    err = rt_heap_bind(&heap_desc,  TEST_HEAP ,TM_NONBLOCK);
    if (err)
	return 1;

    if (rt_heap_alloc(&heap_desc,0,TM_NONBLOCK,&shared_mem))
	return 2;

#endif
	
    printf("%s:%d heap %p\n", __FUNCTION__, __LINE__, shared_mem);
    system("pwd");

    pid = fork();
    if (pid < 0) {
	printf("%s:%d errno %d\n", __FUNCTION__, __LINE__, errno);
	return 3;
    }
    
    if (pid == 0) {
	printf("%s:%d\n",  __FUNCTION__, __LINE__);
	printf("%s:%d [%d] pid %d\n", __FUNCTION__, __LINE__, getpid(), pid);
	sleep(1);
	exit(EXIT_RC);
    } else {
	int s;

	printf("%s:%d [%d] pid %d\n", __FUNCTION__, __LINE__, getpid(), pid);

	waitpid(pid, &s, 0);
	printf("%s:%d [%d] pid %d, status %08x\n", __FUNCTION__, __LINE__, getpid(), pid, s);
	printf("%s:%d [%d] pid %d, WIFSIGNALED %u, WIFEXITED %u, rc %u\n", __FUNCTION__, __LINE__, getpid(), pid, 
	    WIFSIGNALED(s), WIFEXITED(s), WEXITSTATUS(s));
	err = (!WIFSIGNALED(s) && WIFEXITED(s) && (WEXITSTATUS(s) == EXIT_RC)) ? 0 : 4;
    }

#ifdef _XENO_SHMEM_
    rt_heap_unbind(&heap_desc);
#endif    
    printf("%d\n", err);

    return err;
}


#endif

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

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

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

[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

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

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

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

[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

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

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

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

[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

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

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

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

[Krzysztof Błaszkowski]

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

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

[-- Attachment #2: libc.so --]
[-- Type: application/x-sharedlib, Size: 238 bytes --]

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

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

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

[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

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

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

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

[Krzysztof Błaszkowski]

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

Hi Gilles,

I do have good and bad news.

Bad one is that rev 2.5.4 works same as 2.5.3
Good one is that i predicted this ;)

If you need some additional tries of anything then let me know.


On Tue, 2010-08-17 at 16:17 +0200, Gilles Chanteperdrix wrote:
> 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.
> 


-- 
Krzysztof Blaszkowski

[-- Attachment #2: xeno-254-and-fork.jpeg --]
[-- Type: image/jpeg, Size: 99118 bytes --]

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

[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

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

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

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

[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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

-- 
Philippe.

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

[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@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Krzysztof Blaszkowski

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

[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 00000b00
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.

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

[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 00000b00
> 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 r&d 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 =>  (0xffffe000)
	libnative.so.3 => not found
	libxenomai.so.0 => not found
	libc.so.6 => /lib/libc.so.6 (0xf7da5000)
	/lib/ld-linux.so.2 (0xf7f10000)

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 0000000b
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 r&d.

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 r&d test box)

> 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 ?

Regards,

-- 
Krzysztof Blaszkowski

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

[Gilles Chanteperdrix]

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 r&d 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).

> 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 =>  (0xffffe000)
> 	libnative.so.3 => not found
> 	libxenomai.so.0 => not found
> 	libc.so.6 => /lib/libc.so.6 (0xf7da5000)
> 	/lib/ld-linux.so.2 (0xf7f10000)
> 
> when compiled without pthreads.

libnative depends on pthread, if ldd had been able to find libnative, it
 would have found the dependency on libpthread.


>> - your user-space code was missing #include <unistd.h>
> 
> i added. it changed nothing.

Ok, with all other changes I assume?

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

What version of opensuse? If several toolchains are available, which one
are you using? 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.

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

-- 
					    Gilles.

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

[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 r&d 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 =>  (0xffffe000)
> > 	libnative.so.3 => not found
> > 	libxenomai.so.0 => not found
> > 	libc.so.6 => /lib/libc.so.6 (0xf7da5000)
> > 	/lib/ld-linux.so.2 (0xf7f10000)
> > 
> > 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 r&d.
> > 
> > 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
Linux atest 2.6.31.8-xeno254 #1 Tue Aug 17 17:48:32 CEST 2010 i686 i686
i386 GNU/Linux
atest:~/xeno-test-254 # 

-- 
Krzysztof Blaszkowski

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

[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 r&d 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.

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

[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 r&d 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

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

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

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

[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

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

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

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

[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

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

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

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

[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

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

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

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

[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 00000b00
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

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

[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 00000b00
> 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.

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

[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 00000b00
> > 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

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

[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 00000b00
>>> 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.

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

[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 00000b00
> >>> 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

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

[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 00000b00
> >>> 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

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

[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 00000b00
> >>> 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

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

[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

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

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

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

[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

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

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

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

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

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

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

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

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

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

[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

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

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