https://lkml.org/lkml/2003/2/26/158 I've pushed a fix. When code changes as much as it has in the past week, there are bound to be minor glitches. Thanks to everyone for bug reports and feedback. Alan DeKok.
Hi,
https://lkml.org/lkml/2003/2/26/158
I've pushed a fix.
When code changes as much as it has in the past week, there are bound to be minor glitches.
Thanks to everyone for bug reports and feedback.
it fixed something....but has now revealed another hopefully more easy, issue Module: Instantiating eap-tls tls { tls = "tls-common" ASSERT FAILED src/main/conffile.c[964]: type < PW_TYPE_MAX Aborted alan
On 20 Feb 2013, at 12:37, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
https://lkml.org/lkml/2003/2/26/158
I've pushed a fix.
When code changes as much as it has in the past week, there are bound to be minor glitches.
Thanks to everyone for bug reports and feedback.
it fixed something....but has now revealed another hopefully more easy, issue
Module: Instantiating eap-tls tls { tls = "tls-common" ASSERT FAILED src/main/conffile.c[964]: type < PW_TYPE_MAX Aborted
No that was added previously to catch the issue earlier. That means you're still experiencing the same issue. Did you re-run configure before making? -Arran
Hi,
No that was added previously to catch the issue earlier. That means you're still experiencing the same issue.
Did you re-run configure before making?
yep. scoured the system for rlm_ files - only present in build directories and /usr/lib (prefix=/usr) , deleted them and the freeradius lib. deleted the freeradius-server directory. fresh git clone ./configure --prefix=/usr --enable-shared --with-large-files --with-raddbdir=/etc/raddb --with-snmp --with-experimental-modules make make install radiusd -X same error Module: Instantiating eap-tls tls { tls = "tls-common" ASSERT FAILED src/main/conffile.c[964]: type < PW_TYPE_MAX Aborted (even if I double check with an 'ldconfig -v') alan
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
A.L.M.Buxey@lboro.ac.uk wrote:
same error
Kill it with fire. We did a "git bisect" on the code, and didn't see anything that would help. i.e. we ran into git refusing to continue the bisect. <sigh>
Module: Instantiating eap-tls tls { tls = "tls-common" ASSERT FAILED src/main/conffile.c[964]: type < PW_TYPE_MAX Aborted
Arran is doing a 32-bit coverity build on Centos now. If that doesn't find anything, I'll start sacrificing chickens. Alan DeKok.
On 20 Feb 2013, at 17:31, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
same error
Kill it with fire.
We did a "git bisect" on the code, and didn't see anything that would help. i.e. we ran into git refusing to continue the bisect. <sigh>
Module: Instantiating eap-tls tls { tls = "tls-common" ASSERT FAILED src/main/conffile.c[964]: type < PW_TYPE_MAX Aborted
Arran is doing a 32-bit coverity build on Centos now. If that doesn't find anything, I'll start sacrificing chickens.
Alan just fixed it. Turned out to be the configuration definition wasn't properly NULL terminated, so the config parser carried on parsing random crap. Anyway, patch pushed. Hopefully the LDAP lock ups and connection pool issues are sorted now too. -Arran
On 21.02.2013 05:02, Arran Cudbard-Bell wrote:
Alan just fixed it. Turned out to be the configuration definition wasn't properly NULL terminated, so the config parser carried on parsing random crap.
Anyway, patch pushed.
Hopefully the LDAP lock ups and connection pool issues are sorted now too.
Been testing it with the latest commit for a while. SIGPIPE is still there, but as discussed yesterday, it happens in libldap, and is normally handled by it. so adding "handle SIGPIPE nostop noprint pass" to gdb solved this situation. And no more seg fault or lock after 1h of testing. So closing the issue on github Thanks for fix ! Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org
Hi,
Alan just fixed it. Turned out to be the configuration definition wasn't properly NULL terminated, so the config parser carried on parsing random crap.
Anyway, patch pushed.
Hopefully the LDAP lock ups and connection pool issues are sorted now too.
cool. strange how the world of new OS and 64bit didnt get affected in the same way. many thanks for your help with this....I think the close examination of everything during this hunt may have accelerated the fixing of some other bits so not a waste of time :-) alan
A.L.M.Buxey@lboro.ac.uk wrote:
it fixed something....but has now revealed another hopefully more easy, issue
Module: Instantiating eap-tls tls { tls = "tls-common" ASSERT FAILED src/main/conffile.c[964]: type < PW_TYPE_MAX Aborted
Done. $ git pull I hate esoteric bugs. Alan DeKok.
On 20/02/13 16:57, Alan DeKok wrote:
https://lkml.org/lkml/2003/2/26/158
I've pushed a fix.
When code changes as much as it has in the past week, there are bound to be minor glitches.
Ok, after thoroughly scrubbing /usr/local, /opt, /everywhere/else of anything FR related, doing a fresh clone and configure/make, it's working now. Partly my own stupidity, but I wonder if it's an idea to make the server only load modules built from the same source - maybe embed the git rev/release version number into the module and check it at dynload time?
Phil Mayers wrote:
Partly my own stupidity, but I wonder if it's an idea to make the server only load modules built from the same source - maybe embed the git rev/release version number into the module and check it at dynload time?
Maybe. It's necessary only for debug builds. And it will be hard. You may end up doing 3-4 commits which have minimal effect, and you still want to link against the recently built modules. And you don't want to re-build the modules after every commit. By and large... I always run the server from the build tree. I rarely install it. That makes it easier to force particular modules, dictionaries. etc. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Olivier Beytrison -
Phil Mayers