Thank you very much Philippe. I want to just update you. I tried all possibilities but no luck. While debugging through gdb if I enable "efence" threads are not crashing. I do not know why. Still I will try...
Samba. -----Original Message----- From: Philippe Gerum [mailto:r...@xenomai.org] Sent: Friday, 29. July, 2011 10:50 To: Sambasiva Rao Manchili Cc: Antonio Gambin; xenomai-help@gna.org Subject: Re: [Xenomai-help] Xenomai VxWorks Skin On Fri, 2011-07-29 at 10:32 +0200, Philippe Gerum wrote: > On Fri, 2011-07-29 at 10:26 +0200, Philippe Gerum wrote: > > On Fri, 2011-07-29 at 09:56 +0200, Sambasiva Rao Manchili wrote: > > > Hallo Xenomai Experts, > > > We used Xenomai to quickly port our VxWorks code to Linux. Changes > > > that we need to do for successful compilation and linking were > > > minimal because of Xenomai.Most of our tasks spawned are running > > > with help of Xenomai on Linux 2.6.37. > > > > > Yeah, ok, I should definitely read mails to their end, you did provide > the backtrace already. It says that you definitely have an issue with > malloc when creating the thread. A quick look at the glibc code seems to confirm that you don't have 8Mb of lockable RAM available to create your new thread's stack which ends up causing the glibc to panic. You may want to try to decrease this value to say, 128Kb to play safe (unless you app has unreasonably large automatic data), and resume your investigations from there. > > > > > Which CPU architecture? > > > > > Once we had problem of task being crashed(Thread Segfault) with > > > one of our tasks spawned by a process and after two weeks of > > > debugging and re-verifying every thing found that "stacksize > > > parameter" in the taskSpawn function that was normally running > > > in VxWorks was not enough in the Xenomai Linux environment. After > > > increasint the stack size segmentation fault of taskSpawn was solved. > > > > > > Now again I see SIGABORT in another task. I increase the stack > > > size from 32k to 8MB but still crashes. > > > > That is not a good idea anyway. Since your app data segment must be > > locked in RAM to run in the Xenomai context, you are basically > > throwing away 8Mb of RAM space minus a few tenths of Kb, which > > nobody will ever use. Check mlockall(). > > > > > I am thinking now here in this case increasing stacksize value is > > > not right. Do you have any hints for such problem > > > > Do you have any message along with SIGABRT on your console? It is > > commonly raised by glibc/malloc when something goes wrong. In any > > case, you should run your app over gdb, and ask for a backtrace when > > that signal is caught, to spot the faulty code. > > > > If using gdb live is not an option for whatever reason, then let the > > kernel trigger a core dump (running "ulimit -s <hugevalue>" once for > > the startup shell may be required before launching the app to enable > > such dump), then ask gdb for a post-mortem analysis of this core image. > > > > e.g. gdb /path/to/app /path/to/core > > > > then again, from gdb just run "bt" to get a backtrace. Hopefully > > that backtrace won't be trashed as it might happen with SIGABRT on > > some platforms unfortunately. > > > > > > > > Thanks in advance. > > > Samba. > > > > > > > > > > > > (gdb) where > > > #0 0xffffe424 in __kernel_vsyscall () > > > #1 0x4b0a1df0 in raise () from /lib/libc.so.6 > > > #2 0x4b0a3701 in abort () from /lib/libc.so.6 > > > #3 0x4b0da3ab in __libc_message () from /lib/libc.so.6 > > > #4 0x4b0e33fd in _int_malloc () from /lib/libc.so.6 > > > #5 0x4b0e4cca in calloc () from /lib/libc.so.6 > > > #6 0x4b06af0a in _dl_allocate_tls () from /lib/ld-linux.so.2 > > > #7 0x4b1e0f5d in pthread_create@@GLIBC_2.1 () from > > > /lib/libpthread.so.0 > > > #8 0xb79ae4d2 in __real_pthread_create () from > > > /usr/xenomai/lib/libvxworks.so.1 > > > #9 0xb79ad338 in taskInit () from > > > /usr/xenomai/lib/libvxworks.so.1 #10 0xb79ad49e in taskSpawn () > > > from /usr/xenomai/lib/libvxworks.so.1 > > > #11 0xb7ff3ccb in create_forth_task (entry=0xb4902098, > > > priority=143, > > > special_stack_size=0) at tesarm.c:1774 > > > #12 0xb7ff58d7 in load_interpreter (toffset=1, filetab_index=0 > > > '\000', single=0 '\000') at tesarm.c:851 > > > #13 0xb7ff5bdf in reply_from_file_loader (msg_ptr=0xb44fcf14) at > > > tesarm.c:1400 > > > #14 0xb7ff3465 in handle_ta_request () at tesataLnx.c:126 > > > #15 test_admin_task () at tesataLnx.c:400 > > > #16 0xb79accbe in wind_task_trampoline () from > > > /usr/xenomai/lib/libvxworks.so.1 > > > #17 0x4b1e0832 in start_thread () from /lib/libpthread.so.0 > > > #18 0x4b14b45e in clone () from /lib/libc.so.6 > > > > > > > > > Sambasiva Rao Manchili > > > Software Development Engineer > > > ________________________________ > > > > > > NEXUS TELECOM AG > > > Network and Service Investigation > > > > > > Feldbachstrasse 80 > > > 8634 Hombrechtikon > > > Switzerland > > > > > > Direct/mobile: +41 78 750 6808 > > > Main: +41 44 355 6611 > > > Email: sambasiva.manch...@nexustelecom.com > > > Website: www.nexustelecom.com > > > > > > > > > > > > > > > > > > __________________________________________________________________ > > > ____ This email and any attachment may contain confidential > > > information which is intended for use only by the addressee(s) > > > named above. If you received this email by mistake, please notify > > > the sender immediately, and delete the email from your system. You > > > are prohibited from copying, disseminating or otherwise using the > > > email or any attachment. > > > _______________________________________________ > > > Xenomai-help mailing list > > > Xenomai-help@gna.org > > > https://mail.gna.org/listinfo/xenomai-help > > > -- Philippe. This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
