double free or corruption errors with 2.0.0-pre0
Grabbed 2.0.0-pre0 from CVS (the latest, I presume) on a RHEL4 system with perl 5.8.8. Running /usr/local/sbin/radiusd -X gives: radiusd: entering modules setup Module: Library search path is /usr/lib modules: Not loading pre-proxy{} section modules: Not loading post-proxy{} section *** glibc detected *** double free or corruption (fasttop): 0x08c47478 *** Aborted I found some mention of upgrading perl (default RHEL is 5.8.2, I upgraded to 5.8.8) but still get those errors after a clean compile. I'm configuring with the following: ./configure \ --enable-shared --disable-static \ --with-gnu-ld \ --with-threads \ --with-thread-pool \ --disable-ltdl-install \ --sysconfdir=/etc/ Any fix for this? -- matthew zeier | Network Engineer | Mozilla Corp. | (650)903-0800 x219
matthew zeier wrote:
Grabbed 2.0.0-pre0 from CVS (the latest, I presume) on a RHEL4 system with perl 5.8.8.
Running /usr/local/sbin/radiusd -X gives:
radiusd: entering modules setup Module: Library search path is /usr/lib modules: Not loading pre-proxy{} section modules: Not loading post-proxy{} section *** glibc detected *** double free or corruption (fasttop): 0x08c47478 *** Aborted
Hm... I've been running the server under valgrind, and haven't seen that issue recently. Can you post more information that might let us figure out where the problem is? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
What sort of additional information would be useful? If it matters, I was having the same problem with 1.1.5. Alan DeKok wrote:
matthew zeier wrote:
Grabbed 2.0.0-pre0 from CVS (the latest, I presume) on a RHEL4 system with perl 5.8.8.
Running /usr/local/sbin/radiusd -X gives:
radiusd: entering modules setup Module: Library search path is /usr/lib modules: Not loading pre-proxy{} section modules: Not loading post-proxy{} section *** glibc detected *** double free or corruption (fasttop): 0x08c47478 *** Aborted
Hm... I've been running the server under valgrind, and haven't seen that issue recently. Can you post more information that might let us figure out where the problem is?
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- matthew zeier | Network Engineer | Mozilla Corp. | (650)903-0800 x219
matthew zeier wrote:
What sort of additional information would be useful?
doc/bugs i.e. WHERE the double free is. The message you showed says "something went wrong.". That's nice. Which line of code needs to be changed? Changing a line at random won't help. Hence the need to know where the problem is.
If it matters, I was having the same problem with 1.1.5.
Yes. That's fixed, and will be released in 1.1.6. Alan DeKok. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
matthew zeier wrote:
What sort of additional information would be useful?
doc/bugs
i.e. WHERE the double free is. The message you showed says "something went wrong.". That's nice. Which line of code needs to be changed?
How would I know where the double free is? Just running 'radiusd -X' spit out that error just before failing to run.
Changing a line at random won't help. Hence the need to know where the problem is.
If it matters, I was having the same problem with 1.1.5.
Yes. That's fixed, and will be released in 1.1.6.
How can I get that version?
matthew zeier wrote:
How would I know where the double free is? Just running 'radiusd -X' spit out that error just before failing to run.
As I said before: doc/bugs It contains "documentation" that may help. It's pointed to from the web page, and other places.
Yes. That's fixed, and will be released in 1.1.6.
How can I get that version?
As noted recently on this list, 1.1.6 will be released next week. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
matthew zeier wrote:
How would I know where the double free is? Just running 'radiusd -X' spit out that error just before failing to run.
As I said before: doc/bugs
Doesn't dump core so all I got was: Starting program: /usr/local/sbin/radiusd [Thread debugging using libthread_db enabled] [New Thread -1208875328 (LWP 24555)] *** glibc detected *** double free or corruption (fasttop): 0x09db5988 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1208875328 (LWP 24555)] 0x00f397a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
matthew zeier wrote:
Doesn't dump core so all I got was:
As you posted before. Let me clear: I cannot reproduce this problem here. No one else has seen the same problem. One inescapable conclusion is that your machine has the information as to what the problem is. Another inescapable conclusion is that no one here but you has access to your machine. You now have a choice. You can do whatever it takes to help solve the problem, including reading documentation for how glibc's double free works, and how to get more information out of it. You can offer to give people an account on your machine so that people with more experience than you can debug the problem for themselves. Or, you can keep posting the same error message, and wondering why the problem hasn't been fixed. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
matthew zeier wrote:
Doesn't dump core so all I got was:
As you posted before.
Let me clear: I cannot reproduce this problem here. No one else has seen the same problem.
I find that hard to believe since google found a number of hits (http://tinyurl.com/2daram is a good example) to the same error I was seeing with FreeRADIUS without any solutions that wfm (I upgraded perl and grabbed from cvs, as suggested a number of times)
You now have a choice. You can do whatever it takes to help solve the problem, including reading documentation for how glibc's double free works, and how to get more information out of it. You can offer to give people an account on your machine so that people with more experience than you can debug the problem for themselves.
Or, you can keep posting the same error message, and wondering why the problem hasn't been fixed.
This list has so far provided the least amount of help for any open source tool I've ever used. I'm an end user, not a developer so digging into how glibc works is beyond my scope. You directed me at docs/bugs and I followd that - didn't get anything from that other than what I posted (which, incidentally, was more that I posted the last time). Since I'm running stock RHEL4, this should be easy to duplicate. Are you suggesting that if Mozilla gave you a RHEL4 system, you'd be able to fix it? If that's what you're saying, send me your public key and I'll have a host online tonight. - mz
matthew zeier wrote:
I find that hard to believe since google found a number of hits (http://tinyurl.com/2daram is a good example)
Which is in 1.1.5. I have already told you multiple times that it's known, and will be fixed in 1.1.6. Please read my messages. What *isn't* known is a double free bug in 2.0-pre0. As I said, I haven't seen it, and neither has anyone else. Responding that there is a known double-free bug in 1.1.5 is beside the point. The code in 1.1.5 is *very* different than 2.0.
This list has so far provided the least amount of help for any open source tool I've ever used.
Is this the way I should behave if I file a bug in Mozilla? "Stuff went wrong in 2.0, here's a pointer to a similar bug report in 1.5. Why haven't you people fixed it already?" Honestly? Is it such a shock when someone tells you that you need to participate in the solution to a problem that only you're seeing?
Since I'm running stock RHEL4, this should be easy to duplicate. Are you suggesting that if Mozilla gave you a RHEL4 system, you'd be able to fix it?
No. Maybe I can try, though.
If that's what you're saying, send me your public key and I'll have a host online tonight.
Attached. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2comcplgH4DPwo2LFc556rgya64F2a40k0JcayGf1eJlRRGd8BrDPFOuZamzsKPkZQDXufQ4qXDom55bcG7sgdOvgG3xsBwSV13X05uNoUb7Ak30MBZcqyYzjhbykt923XDTxg5x7Q4kBPSaeOkouQbbACsadwBzcnCfpSuod60= Customer@thor
I think you need to step back and relax, Mat. If a developer can't get the situation reproduced or even debug info on it, they'll be helpless. Do also realize this is an open source free utility that doesn't come with any guaranteed support. Was this a problem for you in 1.1.4? I know for me it wasn't (and because of that I've rolled back), but I also know that it started popping up when I decided to compile on new AMD Opteron based systems (1.1.5 worked on my Intel servers just fine, oddly enough, with the EXACT same OS setup and config of 1.1.5 copied over through VMWare!) Alan, you said 1.1.6 will be addressing this specific issue, or is it something I should continue looking into? Do you have a schedule posted for 2.0.0. -- View this message in context: http://www.nabble.com/double-free-or-corruption-errors-with-2.0.0-pre0-tf353... Sent from the FreeRadius - User mailing list archive at Nabble.com.
ChristosH wrote:
Alan, you said 1.1.6 will be addressing this specific issue, or is it something I should continue looking into?
There is a known double free in 1.1.5 that will be fixed in 1.1.6. That should be released this week.
Do you have a schedule posted for 2.0.0.
Soon. At this point, many of the fixes needed for 2.0 are in, so it should be very, very, soon. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Can I return VSA(106) from a script called from exec-prog-wait? I am trying to "echo H323-redirect-number=1111" but the NAS does not see this as VSA 106 Thanks murray
Murray Hooper wrote:
Can I return VSA(106) from a script called from exec-prog-wait? I am trying to "echo H323-redirect-number=1111" but the NAS does not see this as VSA 106
If you run the serber in debugging mode, as suggested in the FAQ, README, and INSTALL, you will see the results of exec-program-wait, and what the server is doing with it. I never understand why people look at the NAS to see what the server is doing. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
-----Original Message----- From: freeradius-users-bounces+m-hooper=rogers.com@lists.freeradius.org [mailto:freeradius-users-bounces+m- hooper=rogers.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, April 11, 2007 12:20 AM To: FreeRadius users mailing list Subject: Re: returning VSA from exec-prog-wait
Murray Hooper wrote:
Can I return VSA(106) from a script called from exec-prog-wait? I am trying to "echo H323-redirect-number=1111" but the NAS does not see this as VSA 106
If you run the serber in debugging mode, as suggested in the FAQ, README, and INSTALL, you will see the results of exec-program-wait, and what the server is doing with it.
I never understand why people look at the NAS to see what the server is doing.
Alan DeKok. --
After running the server in debugging mode as suggested I did see everything that I expected FreeRadius to be doing and that is why I originally wrote the inquiry. This unfortunately was not triggering the NAS to respond as recognizing the variable. The expected line from exec-prog-wait ended up being echo 'vsa106 vsa106=string' that was needed in the script being called from exec-prog-wait. Unfortunately, I must have missed this in the examples and FAQ's. Again thanks for the help murray
After running the server in debugging mode as suggested I did see everything that I expected FreeRadius to be doing
Including sending the attribute back to the NAS?
and that is why I originally wrote the inquiry. This unfortunately was not triggering the NAS to respond as recognizing the variable.
You may be confusing two separate issues: 1) Get the server to respond to the NAS with the attribute you want 2) Get the NAS to understand the attribute, and use it. If you have (1) working, but (2) doesn't, the answer is to read the NAS documentation to see what attribute it expects... which aren't the ones you're sending.
The expected line from exec-prog-wait ended up being echo 'vsa106 vsa106=string' that was needed in the script being called from exec-prog-wait.
I find that more than a little surprising. The server doesn't parse attributes in that format from exec-program-wait.
Unfortunately, I must have missed this in the examples and FAQ's.
I think there's something else going on. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (4)
-
Alan DeKok -
ChristosH -
matthew zeier -
Murray Hooper