#linuxcnc-devel Logs
Apr 20 2020
#linuxcnc-devel Calendar
05:31 AM rmu|w: ../bin/xhc-whb04b-6 doesn't link for me
05:35 AM rmu|w: latest HEAD
05:35 AM rmu|w: I think -lusb1.0 has to be moved to the end of the objects list
05:35 AM andypugh: Which OS?
05:36 AM andypugh: It’s building on the buildbot.
05:36 AM rmu|w: strange
05:37 AM andypugh: But then none of the buildbots are using gcc7.5
05:37 AM andypugh: (The list, again) http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
05:37 AM rmu|w: the gcc version should be of no consequence
05:38 AM rmu|w: i think i have some shared lib issue
05:38 AM andypugh: Apparently it doesn’t even compile on Mint
05:43 AM rmu|w: what's the problem on mint?
05:45 AM andypugh: I wish I knew.
05:45 AM rmu|w: hmm. seems i'm on 2.8 branch, the problem is fixed on head
05:46 AM andypugh: Really?
05:47 AM rmu|w: my linking problem
05:47 AM rmu|w: compare https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/xhc-whb04b-6/Submakefile#L23 vs. https://github.com/LinuxCNC/linuxcnc/blob/2.8/src/hal/user_comps/xhc-whb04b-6/Submakefile#L44, the position of $(XHC_WHB04B6_LIBS)
05:47 AM andypugh: But what, on master, “fixed” the problem?
05:49 AM andypugh: What on earth?
05:51 AM rmu|w: sorry i'm confused
05:51 AM rmu|w: my local "origin/master" branch looks different from github
05:52 AM rmu|w: but i'm on the same hash
05:54 AM andypugh: It seems that there were some fixes from jepler that I failed to pull in.
05:56 AM rmu|w: so my local checkout is in order again, building master
06:30 AM andypugh: Whem that is done. can you try 2.8 again? I pushed some fixes that had been left behind.
06:37 AM rmu|w: master did build. trying 2.8
06:39 AM rmu|w: 2.8 complains a lot about "‘-Werror=implicit-function-declaration’ is not valid for C++"
06:40 AM rmu|w: but that may be the compiler
06:40 AM andypugh: In which files?
06:41 AM rmu|w: .cc files, probably all of them
06:42 AM andypugh: Can you look in Makefile.inc and see what the CXXFLAGS is set to?
06:43 AM rmu|w: CXXFLAGS = -g -O2
06:44 AM andypugh: Aha!
06:44 AM andypugh: As a quick test append -std=c++11 to that line
06:47 AM rmu|w: that should change the -Werror warning? it does not.
06:47 AM rmu|w: I think implicit function declarations are not allowed in c++, so it is an error regardless of compiler settings
06:48 AM rmu|w: trying to find relevant gcc doc
06:50 AM andypugh: Ah, thinking about it, your comiler probably supports C++11 by default, it is only 4.7 that needs that flag.
06:58 AM rmu|w: still compiling. old and slow maching.
06:59 AM rmu|w: machine
07:17 AM rmu|w: build finished successfully
07:27 AM rene_dev_: Rmu pocket fix is merged in master, you can try it
07:28 AM rmu|w: yeah, rebuilding master just now
07:29 AM rmu|w: not sure how to test it, probably will for now just add logging of pocket nr to the g-code routines
07:43 AM rmu|w: master doesn't have -Werror=implicit-function-declaration in the makefile
07:43 AM linuxcnc-build: build #3909 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/3909 blamelist: Jeff Epler <jepler@gmail.com>
07:44 AM linuxcnc-build: build #3906 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/3906 blamelist: Jeff Epler <jepler@gmail.com>
07:47 AM linuxcnc-build: build #4166 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/4166 blamelist: Jeff Epler <jepler@gmail.com>
07:57 AM linuxcnc-build: build #5337 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/5337 blamelist: Jeff Epler <jepler@gmail.com>
07:58 AM linuxcnc-build: build #5337 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/5337 blamelist: Jeff Epler <jepler@gmail.com>
08:08 AM linuxcnc-build: build #3199 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/3199 blamelist: Jeff Epler <jepler@gmail.com>
08:32 AM linuxcnc-build: build #3168 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/3168 blamelist: Jeff Epler <jepler@gmail.com>
08:54 AM linuxcnc-build: build #3596 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/3596 blamelist: Jeff Epler <jepler@gmail.com>
08:58 AM linuxcnc-build: build #2578 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/2578 blamelist: Jeff Epler <jepler@gmail.com>
08:59 AM linuxcnc-build: build #2575 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/2575 blamelist: Jeff Epler <jepler@gmail.com>
09:00 AM linuxcnc-build: build #2467 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/2467 blamelist: Jeff Epler <jepler@gmail.com>
09:04 AM linuxcnc-build: build #2465 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/2465 blamelist: Jeff Epler <jepler@gmail.com>
09:30 AM rene_dev_: rmu|w good catch, I think I lot it during one of the merges yesterday
09:39 AM rmu|w: now i have to deal with some strange new estop issues...
09:39 AM rmu|w: testing of the pocket stuff will have to wait
10:22 AM rmu|w: so after updating to latest master (2.8 seems to be the same), gmoccapy is not working any more, it says "HAL: ERROR: insufficient memory for signal 'rs.X.I107.0'"
10:23 AM rmu|w: changing gmoccapy to axis or some other interface like probe_basic doesn't have this issue
10:44 AM rmu|w: axis doesn't like multiple tools in pocket 0
10:44 AM Tom_L: i can't imagine why
11:05 AM rene_dev_: aah, you cant have that :D
11:06 AM Tom_L: a program with good error checking wouldn't allow it either
11:06 AM Tom_L: but it should be common sense
11:07 AM rene_dev_: the gcode doesnt deal with pockets
11:07 AM Tom_L: no that's up to the tool changer etc
11:07 AM Tom_L: the tool table does i believe
12:40 PM rmu|w: so how do you realise a situation where you have 10 pockets in your ATC and the other tools have to be swapped in manually
12:40 PM rmu|w: s/realise/implement/
12:46 PM Tom_L: never had one with not enough pockets :)
12:46 PM Tom_L: maybe call up tool 0 and do the manual change but your tool offset would be wrong
12:47 PM rmu|w: i would like to call the prober tool number, assign it a pocket number 0, and then the machine moves to the proper location for manual tool change
12:47 PM rmu|w: proper
12:48 PM -!- #linuxcnc-devel mode set to +v by ChanServ
12:48 PM cradek: when you set up a job, put the tools you need into the machine and set their lengths
12:49 PM rmu|w: cradek: what do i do with the "other" tools? say i have a library of 20 tools, all in their holders, offsets measured etc...
12:49 PM Tom_L: i think he was indicating a situation where there may not be enough pockets?
12:49 PM Tom_L: rmu|w, would you be using all 20 on the job?
12:50 PM rmu|w: even if i only need 10 tools for a job and have 10 pockets, i don't want to renumber tools or mess with teh tool table too much
12:50 PM Tom_L: it's hard to manage if you don't have enough pockets
12:50 PM cradek: set them aside I guess...
12:50 PM Tom_L: i'm afraid you may have to assign the pockets on a per job basis
12:50 PM rmu|w: so ideally i would configure pocket numbers in the tool table
12:51 PM cradek: I think it's a mistake to worry about pocket numbers. some machines even move the tools around into various pockets (mine does)
12:51 PM Tom_L: if you knew ahead of time certain tools would never be used on the same job you could assign the same pockets to some
12:51 PM rmu|w: but it seems pocket numbers are only valid for random tool changers and for non-random toolchangers a fixed mapping tool <-> pocket is assumed
12:51 PM rmu|w: with tool number = pocket number
12:51 PM cradek: if you want T1 to be something new, load up T1, pop it out of the spindle, put in the tool you want, measure it.
12:52 PM Tom_L: there's not a good solution for this
12:52 PM Tom_L: there are workable ones
12:52 PM skunkworks: I don't know why you don't just read the tool number off the tool. problem solved.
12:52 PM skunkworks: ;)
12:52 PM skunkworks: (and this was in the 60's)
12:52 PM Tom_L: skunkworks, 20 tools, 10 pockets
12:52 PM rmu|w: i want to read the pocket number off the tool ;)
12:52 PM cradek: heh yeah skunkworks's machine doesn't care what pockets the tools are in
12:52 PM rmu|w: off the tool table
12:53 PM cradek: tools have tool numbers
12:53 PM skunkworks: you guys are so 50's\
12:53 PM cradek: machines may or may not have pocket numbers
12:53 PM cradek: I think you're making a mistake thinking the tool has a pocket number
12:54 PM rmu|w: so how do i tell the machine which tools are in the tool changer?
12:54 PM cradek: if you want to replace T1, issue T1 M6, if there's a tool in the spindle remove it, put in the one you want.
12:55 PM cradek: repeat for each tool needed for the job
12:56 PM Tom_L: just be sure to reset the tool offsets
12:56 PM cradek: right
12:56 PM cradek: measure that new T1 as soon as you put it in
12:56 PM skunkworks: http://electronicsam.com/images/KandT/conversion/Toolreader.JPG
12:56 PM rmu|w: so you say you can't have a tool library that is larger than the number of places you got in the ATC
12:56 PM rmu|w: because tool numbers are always "reassigned"?
12:58 PM rmu|w: i don't understand "reset the tool offsets"
12:58 PM cradek: the way linuxcnc is now, it doesn't have a way to have a tool in the tool table that's not currently in a pocket
12:59 PM rmu|w: that seems like an artificial limitation
12:59 PM cradek: rmu|w: there are many ways to set tool lengths, including measuring in the machine, or measuring in a separate setup
12:59 PM skunkworks: Couldn't you have different tool tables? drop them in?
01:00 PM cradek: on some machines that might make sense. on a random toolchanger you're asking for disaster.
01:00 PM rmu|w: skunkworks: that sucks. because i would need to sync with CAM a bunch of tool tables, not just one.
01:00 PM skunkworks: sure.
01:01 PM rmu|w: skunkworks: also, putting a label on the tool including the number would need another indirection level
01:02 PM rmu|w: currently, i have a mapping tool <-> pocket number that is hardcoded in the ATC g-code
01:02 PM cradek: it always seems to suck, the ways the cam and the control are separate unconnected pieces of software
01:02 PM rmu|w: if pocket number is 0 or "too large", machine moves to manual toolchange place
01:02 PM rmu|w: (puts tool back in ATC, then tries to get manual tool etc...)
01:03 PM rmu|w: but changing G-Code for jobs is not nice. would be easier to use the pocket-number that is already there for the random toolchanger.
01:12 PM sync: seb_kuzminsky: claiming that a 32bit P4 was not obsolete in 2010 is a bit bold
01:13 PM sync: it has to be a northwood one, as all but the earliest prescott had 64bit support
01:20 PM rene_dev_: Rmu cradek you just set up both tools with the same pocket number in the tooltable
01:20 PM rene_dev_: This enables you to have many offsets for the same pocket
01:21 PM rene_dev_: rmu what you describe is the new behavior in master :D
01:23 PM rmu|w: rene_dev_: i assumed to. gmoccapy doesn't check pocket numbers, but it doesn't work at the moment. axis complains
01:23 PM rmu|w: any idea what could cause the "HAL: ERROR: insufficient memory for signal ..." error?
01:35 PM rene_dev_: rmu|w it isnt ui related
01:46 PM rene_dev_: rmu|w could be related to my tool increase, and shm is now too small for more pins
01:46 PM rene_dev_: try making it bigger
02:15 PM andypugh: To chime in a little late. I think is _perfectly_ valid to have multiple tools with the same pocket number. The tool number is the unique identifier and the pocket number is nothing more than the number passed to the tool changer to help it find the tool.
02:16 PM andypugh: (I also think it is valid to have different tools with the same T-number for that matter. Which shouldn’t necessarily be the same as the tool ID.)
02:17 PM andypugh: Anyway, can I have a second opinion?
02:18 PM andypugh: I don’t really grok C++.
02:18 PM andypugh: But my feeling is tha the ERRMSG macro here has no effects and can be removed?
02:18 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/pythonplugin/python_plugin.cc#L36
02:18 PM rmu|w: rene_dev_: it only happens with gmoccapy, and also with recent 2.8 master
02:19 PM rmu|w: andypugh: it does run once. this is a common trick to eat a ;
02:20 PM andypugh: ?
02:20 PM andypugh: I an not talking about the run-once loop
02:20 PM rmu|w: ok
02:20 PM rmu|w: the macro does have an effect, it sets error_msg
02:21 PM andypugh: I guess I need to see if that is shared with any other files.
02:22 PM rmu|w: looks like a global variable
02:22 PM andypugh: Yes, I failed to consider that possibility.
02:23 PM andypugh: Thanks, looks like I can’t just delete it.
02:56 PM andypugh: Another second opinion:
02:56 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/andypugh/statetags-200328/src/hal/classicladder/files_sequential.c#L150
02:57 PM andypugh: There are a few of these. I guess that, as they work, the intention is if ( pCommentString!=NULL) rather than if ( *pCommentString!='\0' )
03:00 PM andypugh: It’s less clear here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/utils/halrmt.c#L2855
03:14 PM rmu|w: it looks for valid empty string, that's different from nullptr, obviously.
03:15 PM andypugh: It’s not so obvious to the compiler
03:16 PM rmu|w: what do you want to change?
03:17 PM andypugh: I want to stop the compiler spitting out woarnings
03:17 PM rmu|w: what is the warning
03:18 PM andypugh: hal/utils/halrmt.c:2861:9: warning: comparison between pointer and zero character constant [-Wpointer-compare]
03:18 PM andypugh: if (s == '\0') return rtCustomHandledError;
03:18 PM andypugh: ^~
03:18 PM andypugh: hal/utils/halrmt.c:2861:7: note: did you mean to dereference the pointer?
03:18 PM andypugh: if (s == '\0') return rtCustomHandledError;
03:20 PM rmu|w: oh i see... didn't get the missing *
03:20 PM andypugh: s is a char* so if we are looking for a zero-length string, should it be *s — ‘/0’
03:21 PM andypugh: It’s not so much a question of what is valid C so much as what the orginal author intended
03:21 PM rmu|w: forget what i said. safe thing probably would be to change all occurences to pCommentString!=NULL && *pCommentString != '\0'
03:22 PM andypugh: That error message was from the second one.
03:22 PM andypugh: (halrmt)
03:22 PM andypugh: That is testing char pointers against NULL all round that spot, so I suspect he did mean *s
03:23 PM rmu|w: ack
03:34 PM rene_dev_: andypugh there are many like it, it depends if the intend is to check a empty string or null pointer
03:35 PM andypugh: I think I have them figured out from context.
03:35 PM andypugh: I am down to two warnigs in 2.8 now :-)
03:35 PM rene_dev_: go and install the clang analyzer for endless fun :D
03:36 PM andypugh: hal/classicladder/files.c:77:3: warning: passing argument 1 to restrict-qualified parameter aliases with argument 2 [-Wrestrict]
03:36 PM andypugh: strcpy( s, s+strlen( S_LINE ) );
03:36 PM andypugh: Buildbot does clang for us, we don’t need to.
03:36 PM rene_dev_: clang is not the same as the clang static analyzer
03:37 PM rene_dev_: https://imgur.com/a/sHy3R3t
03:37 PM rmu|w: i get a number of warnings like this
03:37 PM rmu|w: hal/drivers/mesa-hostmot2/ioport.c:363:20: warning: ‘.gpio.’ directive output may be truncated writing 6 bytes into a region of size between 0 and 47 [-Wformat-truncation=]
03:37 PM rmu|w: "%s.gpio.%03d",
03:37 PM rene_dev_: https://imgur.com/a/M6R92Lx
03:37 PM rmu|w: ^~~~~~
03:38 PM rmu|w: rene_dev_: thats evil
03:38 PM rene_dev_: but it is usually right about those things
03:39 PM rene_dev_: like the bug in halrun I found :D
03:39 PM andypugh: rmu|w: I have spent most of today squashinf truncation warnings in 2.8
03:40 PM andypugh: Though, oddly, not that one...
03:41 PM rene_dev_: andypugh how did you fix them?
03:42 PM andypugh: It depends on the situation.
03:42 PM andypugh: (and that’s why it has taken so long)
03:42 PM rene_dev_: Im still working on python3
03:42 PM rene_dev_: Im convinced its not actually that far away
03:45 PM jepler: fwiw I'm not convinced of -Wformat-truncation= diagnostics. For instance, if you go back and write %.37s.gpio.%03.3d or something, trying to make sure the compiler can see the output string always fits, you've created a new maintenance problem in case anybody wants to change the name length to be 63 instead of 47 (say)
03:46 PM jepler: most of those are designed such that, if the format overflows, you don't create a security problem. Probably you get an error at startup because the trailing part of a name didn't fit and you have multiple items with the same name
03:46 PM jepler: but that's not gospel, that's just an opinion from a person who's not actively working on improving things. take it as such
03:46 PM andypugh: I have taken some more seriously than others in my fixes,
03:46 PM rene_dev_: jepler it is now safe, thanks to your patches
03:47 PM andypugh: I will be putting up a PR for review later tonight.
03:49 PM rene_dev_: andypugh look at the way his branch works. force pushing a branch with a million changes, and keepig track of work in a readme file doesnt really work with multiple developers...
04:00 PM andypugh: Is this just a really clunky way to concatenate two strings?
04:00 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/classicladder/files.c#L75
04:00 PM jepler: when you're not actively trying to collaborate with others, force-pushing is a sensible way to work. But if you want to start working with others, it would be better to change your strategy
04:01 PM jepler: I have no idea what those lines do :-P
04:02 PM rene_dev_: andypugh classicladder is full of warnings. look at the updated upstream version, some are fixed.
04:02 PM andypugh: I have been looking at it for longer than you, and I think it really is just string concatenation with a guaranteed null terminator
04:02 PM rene_dev_: yes
04:02 PM rene_dev_: looks like it
04:03 PM andypugh: so, it could be snprintf(s, size(s), “%s%s”, s1 s2”)
04:03 PM rmu|w: ad-hoc-implementation of something like strncpy?
04:04 PM rene_dev_: http://www.cplusplus.com/reference/cstring/strncat/
04:05 PM rene_dev_: gues what, people have been concatenating strings before ;)
04:05 PM andypugh: snprintf is better, you can detect overrun and act on it
04:05 PM andypugh: and it guarantees a null termination.
04:05 PM andypugh: (I believe)
04:08 PM jepler: strncat is awful like strncpy, because it does not guarantee nul termination
04:08 PM rmu|w: https://www.cplusplus.com/reference/cstdio/snprintf/ "A terminating null character is automatically appended after the content written."
04:09 PM jepler: snprintf isn't good for concatenating onto an existing string, because snprintf(buf, n, "%s%s", buf, new_content)' is forbidden
04:09 PM jepler: nonstandard strlcat is better for concatenating onto an existing string, except for being nonstandard
04:10 PM rmu|w: strncpy_s, standard sind C11
04:10 PM rmu|w: since
04:11 PM jepler: do all our target platforms have it though?
04:13 PM rmu|w: checking, but don't thing so
04:14 PM jepler: rtapi_strlcat and rtapi_strlcpy were added by that patchset fwiw
04:14 PM jepler: the one that was so graciously revived and recently merged
04:14 PM linuxcnc-build: build #3300 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/3300 blamelist: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>, Rene Hopf <renehopf@mac.com>
04:16 PM andypugh: Just to add to the fun, as far as I can tell S_LINE == E_LINE == “”
04:17 PM rmu|w: strlcpy and strlcat should be available in -lbsd
04:19 PM rene_dev_: ah, I didnt know about the null termination
04:19 PM rene_dev_: differente
04:22 PM rmu|w: nearly all c string functions from k&r times are somehow broken, insecure and/or incorrect
04:24 PM linuxcnc-build: build #6694 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6694 blamelist: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>, Rene Hopf <renehopf@mac.com>
04:24 PM andypugh: Real Programmers don’t use Strings
04:26 PM andypugh: I just downlaoded the latest CL source, and that file is unchanged since 2001
04:27 PM andypugh: (I was hoping for an easy fix)
04:27 PM andypugh: Now I need to work out exactly what it is tryint to do
04:29 PM andypugh: Or delete it… As currently I think that strlen(S_LINE) = 0.
04:33 PM rmu|w: seems files.h defines S_LINE to ""
04:34 PM rene_dev_: rmu|w I know they are all broken in their own way :D
04:35 PM rmu|w: rene_dev_: there is hope, at least in c++20, with span and string_view
04:36 PM jepler: rmu|w: -lbsd doesn't help for kernel space stuff like linuxcnc with rtai realtime
04:37 PM rmu|w: jepler: i didn't understand your comment about the graciously revived patchset, but if there are rtapi_strlcpy & co, why not use that
04:38 PM jepler: I wrote a patch several years ago to reduce the grossly unsafe API use (sprintf, strcpy) and rene_dev recently revived and applied it
04:38 PM jepler: part of that was to add implementations of strlcpy / strlcat with rtapi_ prefixes that are available anywhere in linuxcnc
04:39 PM jepler: of course if I wasn't careful they probably have bugs :( :(
04:54 PM andypugh: Getting close. But I am not sure what this warning means:
04:54 PM andypugh: emc/usr_intf/axis/extensions/emcmodule.cc:291:56: warning: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘class EMC_STAT’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
04:54 PM rene_dev_: HAL: ERROR: exit called before init
04:54 PM rene_dev_: free(): invalid pointer
04:54 PM rene_dev_: home/rene/dev/linuxcnc/scripts/linuxcnc: line 896: 18371 Aborted $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
04:55 PM rene_dev_: how do I find out where this goes wrong?
04:56 PM rmu|w: andypugh: it says you should use "=" instead of memcpy
04:56 PM andypugh: That’s what I thought it meant. But will it work?
04:59 PM andypugh: No, it doesn’t error: no match for ‘operator=’ (operand types are ‘EMC_STAT’ and ‘EMC_STAT*’
05:00 PM andypugh: rene_dev_: Which branch?
05:02 PM rmu|w: andypugh: i didn't mean to do that literally ;)
05:02 PM rene_dev_: python3 stuff, currently a new branch that isnt pushed
05:02 PM andypugh: Hard ro know what your line 896 is then
05:02 PM rmu|w: the compiler wants somebody to write explicit assignment operator/copy-ctor and use that
05:02 PM rene_dev_: thats just the startup script starting axis
05:03 PM rmu|w: rene_dev_: can you run it in a debugger?
05:03 PM andypugh: Yes, but line 896 seems to be “if $DISPLAY”
05:04 PM rene_dev_: https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/linuxcnc.in#L896
05:04 PM rene_dev_: thats not it
05:06 PM rmu|w: rene_dev_: is it possible something in axis is throwing a (python) exception before hal_init was called and this error happens in winding down the program?
05:06 PM rene_dev_: yes
05:07 PM rmu|w: my strategy in such cases with other python programs is bisecting with prints
05:09 PM rmu|w: and then use import pdb; pdb.set_trace() near the suspicious location to enter the debugger
05:12 PM rene_dev_: Python 3.7.3 (default, Dec 20 2019, 18:57:59)
05:12 PM rene_dev_: [GCC 8.3.0] on linux
05:12 PM rene_dev_: Type "help", "copyright", "credits" or "license" for more information.
05:12 PM rene_dev_: >>> import hal
05:12 PM rene_dev_: HAL: ERROR: exit called before init
05:12 PM rene_dev_: free(): invalid pointer
05:12 PM rene_dev_: Aborted
05:12 PM rene_dev_: well, thete is my problem :D
05:22 PM rmu|w: rene_dev_: did you change the PyTypeObject of halobject_type?
06:35 PM andypugh: That’s disappointing. I get a clean build with no warnings here, but the buildbot has 99 warnings. What is different?
06:40 PM andypugh: OK, so it’s obvious when I look, the docs builds have a bunch of warnings
06:40 PM andypugh: Maybe I will look at that tomorrow.
07:25 PM linuxcnc-build: build #3907 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/3907 blamelist: andypugh <andy@bodgesoc.org>
07:25 PM linuxcnc-build: build #3910 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/3910 blamelist: andypugh <andy@bodgesoc.org>
07:29 PM linuxcnc-build: build #5338 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/5338 blamelist: andypugh <andy@bodgesoc.org>
07:31 PM linuxcnc-build: build #5338 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/5338 blamelist: andypugh <andy@bodgesoc.org>
07:32 PM linuxcnc-build: build #4167 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/4167 blamelist: andypugh <andy@bodgesoc.org>
07:39 PM linuxcnc-build: build #3200 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/3200 blamelist: andypugh <andy@bodgesoc.org>
07:42 PM linuxcnc-build: build #3169 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/3169 blamelist: andypugh <andy@bodgesoc.org>
08:24 PM linuxcnc-build: build #3597 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/3597 blamelist: andypugh <andy@bodgesoc.org>
08:34 PM linuxcnc-build: build #2579 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/2579 blamelist: andypugh <andy@bodgesoc.org>
08:35 PM linuxcnc-build: build #2576 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/2576 blamelist: andypugh <andy@bodgesoc.org>
08:36 PM linuxcnc-build: build #2468 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/2468 blamelist: andypugh <andy@bodgesoc.org>
08:39 PM linuxcnc-build: build #2466 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/2466 blamelist: andypugh <andy@bodgesoc.org>
09:12 PM -!- #linuxcnc-devel mode set to +v by ChanServ