Re: [Xenomai-help] find segmentation fault in real-time-task
On 03/09/2012 06:30 PM, Michael Heuer wrote: > Hi guys, I'm posting the first time and i hope you can help me. > > At the moment i have a segmentation fault in the real-time part of my > program (task created with rt_task_create, Xenomai 2.5.6). > > Is there a way to register an signal to print the call-stack? > > If its in the non real-time part the signal is raised and i get my > information but in the real-time part i just get an Segmentation fault > in the shell... Using xenomai does not make any difference with regard to that question: you can, just as without xenomai, register a handler for the SIGSEGV signal. But if the segmentation fault is due to a stack overflow (which, I suspect, is your problem), you will get another segmentation fault in the segmentation fault signal handler, so, you have to use sigaltstack to avoid that, but then using the "backtrace" function to walk the call stack will no longer work, so, you need to use the SA_SIGINFO flag, and walk the stack yourself extracting the stack pointer register value from the "context" argument of the signal handler. This is a little complicated. Another much simpler solution is to use gdb. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] find segmentation fault in real-time-task
Hi guys, I'm posting the first time and i hope you can help me. At the moment i have a segmentation fault in the real-time part of my program (task created with rt_task_create, Xenomai 2.5.6). Is there a way to register an signal to print the call-stack? If its in the non real-time part the signal is raised and i get my information but in the real-time part i just get an Segmentation fault in the shell... Or how can i determine at which position the error occurs? Thanks in advance Michael ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai stop working
On 03/09/2012 07:06 AM, 马强 wrote: > Hi Gilles, > > I have changed mxc_min_delay as follow > mxc_min_delay = ((__ipipe_cpu_freq + 50) / 100) ?: 1; > -> > mxc_min_delay = ((__ipipe_cpu_freq + 25) / 50) ?: 1; > means make min delay form 1us to 2us, and it seems to work well. I need a > longer test to check it out. > > Another issue about this change is whether 2us is long enough? In other > words, Is 2us a threshold value that due to hardware or an assumed value that > make the possibility smaller? if it is the later one, 2us and someone bigger > seems not to be a perfect solution. You can try mxc_min_delay = 0xff, since it is what linux does in the latest release. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
