Hello, yes, thank you, the newly build packages work without problem. So, once againg, thank you.
(Too bad I was not able to solve this myself. But what the hell, maybe one day in the future.) Cern Dne středa 28. listopadu 2018 17:24:39 UTC+1 Schooner napsal(a): > > Hi Cern, > > Now solved the error and new PR made. > > Original removal of hard thread refs had inadvertently removed a line > which added > kernel LD_FLAGS in Makefile.inc.in > > However rather than produce a build or packaging error, or even a runtime > error in amd64 or armhf, this only produced a runtime error in i386. > Because very few people use it, was not notified for quite some while > until you updated. > > Can only speculate that the amd64 and armhf builds have the linkages > satisfied consequentially through other linkages, but i386 does not and > failed on thread creation. > > Package built from this new PR branch tested on i386 as well as local > build on amd64 and all fine. > > Thanks for the report and 'mucking in' and doing some debugging. > Made things much quicker knowing I needed to zero in on anything related > to threads > > New final packages will be in the repo in due course. > In the interim the current packages work fine on i386 too. > > regards > > On 28/11/18 07:23, [email protected] <javascript:> wrote: > > Thanks for looking at the coredump. Debugging with real time in Linux is > certainly different to msvs! > > Possibly line:539, but thanks that is very helpfull > > My main spur to build a i386 machine was to be able to debug the original > commits, which I now can begin. > > The alternative to trying to debug the failure of the complete set of > merged commits, is to reintroduce them > > one by one until it fails and narrow down what specifically caused it. I > think I will go that route, now that I can build RIP > > builds and do that more easily (and now have an idea where the fault is > likely to occur) > > regards > On 11/28/2018 1:38 AM, [email protected] <javascript:> wrote: > > And am I understanding it correctly that it is dying on line 384 of file > src/rtapi/rt-preempt.c, right? > > Cern > > Dne středa 28. listopadu 2018 2:13:54 UTC+1 [email protected] napsal(a): >> >> >> Hello, >> >> OK, I am used to Visual Studio, so gdb (and others) are interesting >> experience. Was able to experiment, that problem is caused (minimally) by >> creating new thread (halcmd newthread ...) and if I am not mistaken by call >> to pthread_create(params). >> >> Commands from terminal: >> >> machinekit@machinekit:~$ DEBUG=5 realtime start >> rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 >> --rtmsglevel=5 --usrmsglevel=5 --halsize=524288 >> warning: removing unused HAL shm segment /linuxcnc-0-00414c32 >> rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt >> --instance=0 >> machinekit@machinekit:~$ halcmd newthread fff 5000000 fp >> <commandline>:0: rc=-1: rtapi_rpc(): reply timeout >> >> machinekit@machinekit:~$ pidof rtapi:0 >> 24452 >> machinekit@machinekit:~$ sudo gdb -p 24452 >> [sudo] heslo pro machinekit: >> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git >> Copyright (C) 2016 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i686-linux-gnu". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>. >> Find the GDB manual and other documentation resources online at: >> <http://www.gnu.org/software/gdb/documentation/>. >> For help, type "help". >> Type "apropos word" to search for commands related to "word". >> Attaching to process 24452 >> [New LWP 24456] >> [New LWP 24457] >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". >> 0xb77afcf9 in __kernel_vsyscall () >> (gdb) c >> Continuing. >> >> Thread 1 "rtapi:0" received signal SIGSEGV, Segmentation fault. >> 0xb7366b18 in allocate_stack (stack=<synthetic pointer>, >> pdp=<synthetic pointer>, attr=0xbf9b1560) at allocatestack.c:414 >> 414 allocatestack.c: Adresář nebo soubor neexistuje. >> (gdb) backtrace >> #0 0xb7366b18 in allocate_stack (stack=<synthetic pointer>, >> pdp=<synthetic pointer>, attr=0xbf9b1560) at allocatestack.c:414 >> #1 __pthread_create_2_1 (newthread=0xb69e302c, attr=0xbf9b1560, >> start_routine=0xb69d1978, arg=0xb69e03ec) at pthread_create.c:539 >> #2 0xb7367230 in __pthread_create_2_0 (newthread=0xb69e302c, >> attr=0xbf9b1560, start_routine=0xb69d1978, arg=0xb69e03ec) >> at pthread_create.c:765 >> #3 0xb69d1d53 in ?? () from /usr/lib/linuxcnc/rt-preempt/rtapi.so >> #4 0xb69cf4f1 in ?? () from /usr/lib/linuxcnc/rt-preempt/rtapi.so >> #5 0xb68c1416 in hal_create_xthread () >> from /usr/lib/linuxcnc/rt-preempt/hal_lib.so >> #6 0x0047af27 in ?? () >> #7 0xb730dd9c in zloop_start () from /usr/lib/i386-linux-gnu/libczmq.so.4 >> #8 0x00479166 in ?? () >> #9 0x004720a5 in main () >> (gdb) >> >> Nov 28 02:08:15 machinekit msgd:0: startup pid=24447 flavor=rt-preempt >> rtlevel=5 usrlevel=5 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 >> version=v0.1~-----~9c3423c >> Nov 28 02:08:15 machinekit msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 >> atomics=gcc intrinsics libwebsockets=2.0.3 >> Nov 28 02:08:15 machinekit msgd:0: configured: sha=9c3423c >> Nov 28 02:08:15 machinekit msgd:0: built: Nov 14 2018 12:37:25 >> sha=9c3423c >> Nov 28 02:08:15 machinekit msgd:0: register_stuff: actual hostname as >> announced by avahi='machinekit.local' >> Nov 28 02:08:15 machinekit msgd:0: zeroconf: registering: 'Log service on >> machinekit.local pid 24447' >> Nov 28 02:08:15 machinekit rtapi:0: 2:rtapi_app:24452:user rtapi:0: >> cannot create core dumps - /proc/sys/fs/suid_dumpable contains 0 >> Nov 28 02:08:15 machinekit rtapi:0: 2:rtapi_app:24452:user you might have >> to run 'echo 1 > /proc/sys/fs/suid_dumpable' as root to enable rtapi_app >> core dumps >> Nov 28 02:08:15 machinekit rtapi:0: 4:rtapi_app:24452:user rtapi: loaded >> from rtapi.so >> Nov 28 02:08:15 machinekit rtapi:0: 4:rtapi_app:24452:user hal_lib: >> loaded from hal_lib.so >> Nov 28 02:08:15 machinekit msgd:0: rtapi:24452:rt rtapi_app_main:195 HAL: >> initializing RT hal_lib support >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24452:rt halg_xinitfv:90 HAL: >> initializing component 'hal_lib' type=4 arg1=0 arg2=0/0x0 >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24452:rt hal_heap_addmem:58 >> HAL: extending arena by 262144 bytes >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24452:rt >> halg_export_xfunctfv:85 HAL: exporting function 'newinst' type 2 fp=0 >> owner=66 >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24452:rt >> halg_export_xfunctfv:85 HAL: exporting function 'delinst' type 2 fp=0 >> owner=66 >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24452:rt halg_xinitfv:271 HAL: >> singleton component 'hal_lib' id=66 initialized >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24452:rt rtapi_app_main:199 >> HAL: RT hal_lib support initialized rc=66 >> Nov 28 02:08:15 machinekit rtapi:0: 4:rtapi_app:24452:user accepting >> commands at ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a >> Nov 28 02:08:15 machinekit rtapi:0: 3:rtapi_app:24452:user rtapi_app:0 >> ready flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-----~9c3423c >> Nov 28 02:08:15 machinekit rtapi:0: 4:rtapi_app:24452:user pid=24452 >> flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-----~9c3423c >> Nov 28 02:08:15 machinekit rtapi:0: 4:rtapi_app:24452:user pid=24452 >> flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-----~9c3423c >> Nov 28 02:08:15 machinekit msgd:0: ulapi:24453:user _ulapi_init(): ulapi >> rt-preempt v0.1~-----~9c3423c loaded >> Nov 28 02:08:15 machinekit msgd:0: ulapi:24453:user halg_xinitfv:271 HAL: >> singleton component 'hal_lib24453' id=70 initialized >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24453:user --halcmd ping >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24453:user halg_exit:293 HAL: >> removing component 72 'halcmd24453' >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24453:user >> ulapi_hal_lib_cleanup:235 HAL: lib_module_id=70 >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24453:user halg_exit:293 HAL: >> removing component 70 'hal_lib24453' >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24453:user halg_exit:315 HAL: >> hal_errorcount()=0 >> Nov 28 02:08:15 machinekit msgd:0: hal_lib:24453:user halg_exit:316 HAL: >> _halerrno=0 >> Nov 28 02:08:16 machinekit msgd:0: zeroconf: registered 'Log service on >> machinekit.local pid 24447' _machinekit._tcp 0 TXT >> "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" >> "instance=15603820-f2aa-11e8-b229-000c6e417379" "service=log" >> "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a" >> Nov 28 02:09:34 machinekit rtapi:0: 4:rtapi_app:24452:user pid=24452 >> flavor=rt-preempt gcc=6.3.0 20170516 git=v0.1~-----~9c3423c >> Nov 28 02:09:34 machinekit msgd:0: ulapi:24481:user _ulapi_init(): ulapi >> rt-preempt v0.1~-----~9c3423c loaded >> Nov 28 02:09:34 machinekit msgd:0: ulapi:24481:user halg_xinitfv:271 HAL: >> singleton component 'hal_lib24481' id=74 initialized >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24481:user --halcmd newthread >> fff 5000000 fp >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt >> hal_create_xthread:156 HAL: creating thread fff, 5000000 nsec fp=1 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt >> rtapi_clock_set_period (res=1) -> 5000000 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt Creating new task 1 >> 'fff:0': req prio 98 (highest=99 lowest=1) stack=32768 fp=1 flags=0 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt Task CPU: 0 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt RTAPI: task 01 >> installed by module 66, priority 98, code: 0xb68c0941 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt halg_pin_newfv:192 >> HAL: creating pin 'fff.time' s32 OUT 0 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt halg_pin_newfv:192 >> HAL: creating pin 'fff.tmax' s32 I/O 0 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt halg_pin_newfv:192 >> HAL: creating pin 'fff.curr-period' s32 OUT 0 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt rtapi_task_start: >> starting task 1 'fff:0' >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt RTAPI: period_nsec: >> 5000000 >> Nov 28 02:09:34 machinekit msgd:0: hal_lib:24452:rt About to >> pthread_create task 1 >> >> Still have no idea why change in makefiles created this problem. (Will >> have to study Make syntax.) >> >> Cern >> >> Dne pátek 23. listopadu 2018 19:20:21 UTC+1 [email protected] napsal(a): >>> >>> >>> If you are up for it, you can try to debug the core dump that you have >>>> >>>> http://www.machinekit.io/docs/code/Debugging-RT-components/ >>>> >>>> I have found that this works quite well on rt-preempt kernels, in >>>> pinpointing exactly what triggered a segfault. >>>> >>>> The log you originally posted shows the error report, but it is far >>>> from certain exactly where this is >>>> occurring, because motion continues to create pins either side of it. >>>> >>> >>> Will try. >>> >> -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
