Back
[02:27:24] <CIA-2> EMC: 03cmorley 07v2.4_branch * r78f202975d8c 10/src/emc/usr_intf/pncconf/pncconf.py: Add a progress bar to mesa pages.
[02:27:26] <CIA-2> EMC: 03cmorley 07v2.4_branch * r21805451e207 10/src/emc/usr_intf/pncconf/pncconf.py: Fix userneeded abs/scale/mux8 component loading
[02:27:27] <CIA-2> EMC: 03cmorley 07v2.4_branch * r5b1378404a3d 10/src/emc/usr_intf/pncconf/pncconf.py: Fix setting of some axis scaling values
[02:27:28] <CIA-2> EMC: 03cmorley 07v2.4_branch * r2dab6f0b2cb2 10/src/emc/usr_intf/pncconf/pncconf.py: Fix readme to display proper mesa info
[10:59:48] <johnt> is the maximum number of tool table entries 48?
[11:06:29] <micges> 56
[11:06:44] <johnt> micges, thanks
[12:15:42] <CIA-2> EMC: 03jthornton 07v2.4_branch * rbf81816d196c 10/docs/src/gcode/tool_compensation.lyx: update tool table info
[12:15:42] <CIA-2> EMC: 03jthornton 07v2.4_branch * r3aba4c6f279f 10/src/emc/usr_intf/pncconf/pncconf.py: Merge branch 'v2.4_branch' of ssh://
[email protected]/git/emc2 into v2.4_branch
[12:15:49] <CIA-2> EMC: 03jthornton 07v2.4_branch * ra353e9b6d1e5 10/docs/src/lathe/lathe-user.lyx: fix reference error
[12:53:23] <skunkworks_> logger_dev: bookmark
[12:53:23] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-06-03.txt
[13:18:27] <dgarr> jepler: re: segfaults at halcomponent.exit(), this is working for me but i may be missing something:
http://www.panix.com/~dgarrett/stuff/0001-allow-multiple-hal-components-per-process.patch
[13:54:10] <jepler> dgarr: the theory being that these resources that you no longer delete or free will be cleaned up at 'realtime stop'?
[13:55:00] <jepler> the change in rtapi_app_exit seems unlikely, as that is a kernel-only routine. did you find that it was necessary?
[14:22:48] <dgarr> i thought the rtapi_app_exit change was reqd but now i cant reproduce a problem -- so no, i amended the patch above
[14:23:36] <dgarr> re theory: i
[14:24:43] <dgarr> i'm not sure, i just know saw the free leading to segfault at next mutex use
[14:25:21] <dgarr> s/*/the rtai_free caused a segfault at the next mutex usage/
[14:50:30] <jepler> does your system still pass the runtests after this? most of them now crash for me, I think because halcmd is segfaulting
[14:50:34] <jepler> http://pastebin.ca/1876660
[14:54:25] <jepler> it's a very old (breezy) system but it's the only one handy for me to test on
[14:54:46] <jepler> and it does pass all runtests but 1 after a few "make it compile again" fixes (the failing one is hostmot2 because the kernel doesn't support firmware loading)
[15:17:57] <dgarr> i had not run those tests, halcmd segfaults, ok i give up, sorry for the trouble
[15:32:57] <jepler> sorry :(
[16:26:25] <SWPadnos> hmmm
[16:30:36] <SWPadnos> jepler, your email brings up an interesting question/problem: if someone uses halcmd in a custom M-code (a lot), HAL will at some point run out of memory for the component struct
[16:31:20] <SWPadnos> (I noticed components 1/0, ie the component struct allocation wasn't reclaimed from when halcmd status was run)
[16:32:38] <SWPadnos> there's a comment at hal_lib.c:325 that talks about reclaiming memory when components exit
[16:38:22] <SWPadnos> hmmm. maybe that isn't a problem, it looks like the free list is maintained and used correctly, so if you would run halcmd several times you'd still see 1/0
[16:38:43] <cradek> oh good, because that sounds bad otherwise
[16:38:49] <SWPadnos> heh, yeah :)