Hi,
I'd suggest changing sql_query() function in sql_postgresql.c to:
...
if (!errormsg) return -1;
...
instead of the current block of code { errormsg = FATAL ERROR }
Well I tried this change, you can see the gdb output at:
Alexander Clouter wrote:
This is a different implosion this time round to your last one. Looks
like Alan's SQL patch simply postponed the SIGSEGV to a different part
of the code. Not sure what should be done, but it looks like errorcode
also needs to be changed (probably set to NULL
Alan DeKok al...@deployingradius.com wrote:
This is a different implosion this time round to your last one. Looks
like Alan's SQL patch simply postponed the SIGSEGV to a different part
of the code. Not sure what should be done, but it looks like errorcode
also needs to be changed
Hi John,
As long as the hammer does the job. At this stage although I'm aware
that RPM packaging is much more powerful my lack of knowledge about it
doesn't allow for a more sensible approach.
Hopefully this will change time ;)
thanks,
Duarte
2009/11/12 John Dennis jden...@redhat.com:
On
Hi Alex,
Again thanks for the help.
2009/11/12 Alexander Clouter a...@digriz.org.uk:
You should also compile the whole thing with optimisations turned off
and debugging symbols in there; you are not doing the former so it might
make it more difficult to work out what is wrong:
Duarte Fonseca fonseca.dua...@gmail.com wrote:
2009/11/12 Alexander Clouter a...@digriz.org.uk:
You should also compile the whole thing with optimisations turned off
and debugging symbols in there; you are not doing the former so it might
make it more difficult to work out what is wrong:
Hi Alan,
If you could point out which specific commit(s) address this issue I
would be very grateful.
Thank you,
Duarte
2009/11/6 Alan DeKok al...@deployingradius.com:
Duarte Fonseca wrote:
Hi list,
Just checking if anyone has any more suggestions on how I should
proceed with this.
A
Duarte Fonseca wrote:
Hi Alan,
If you could point out which specific commit(s) address this issue I
would be very grateful.
$ git log src/modules/rlm_sql/drivers/rlm_sql_postgresql
...
45877bf44b02d418b6fb263a39e5de07ced58b6e
Alan DeKok.
-
List info/subscribe/unsubscribe? See
Duarte Fonseca fonseca.dua...@gmail.com wrote:
If you could point out which specific commit(s) address this issue I
would be very grateful.
One day we will persaude Alan to put something more verbose in the git
commit logs :)
Until then:
git log -p -n1
Thanks Alan and Alex,
I thought it was that one, just wanted to make sure as I gave it a
quick test and it seems the problem is still there.
I'm doing some more tests to make sure it's not me doing something
silly, I'll be in touch if I keep having problems (hopefully with gdb
and valgrind
Hi again,
So the problem seems to still be present, this is how I'm testing,
please let me know if I'm doing something wrong.
I got the redhat SRPM from
http://people.redhat.com/jdennis/freeradius-rhel-centos/src/freeradius2-2.1.7-2.el5.src.rpm
Applied the change to the source file and built
On 11/12/2009 11:38 AM, Duarte Fonseca wrote:
Hi again,
So the problem seems to still be present, this is how I'm testing,
please let me know if I'm doing something wrong.
I got the redhat SRPM from
http://people.redhat.com/jdennis/freeradius-rhel-centos/src/freeradius2-2.1.7-2.el5.src.rpm
Hi John,
The only change I did to the spec file was change the release (and
later add the --enable-developer)
What I did do was go to the SOURCES dir and unpack the
freeradius-server archive, change the file in question, pack up
freeradius-server replacing the original tar.bz2 archive.
I did
On 11/12/2009 12:28 PM, Duarte Fonseca wrote:
Hi John,
The only change I did to the spec file was change the release (and
later add the --enable-developer)
What I did do was go to the SOURCES dir and unpack the
freeradius-server archive, change the file in question, pack up
freeradius-server
Duarte Fonseca fonseca.dua...@gmail.com wrote:
So the problem seems to still be present, this is how I'm testing,
please let me know if I'm doing something wrong.
I got the redhat SRPM from
http://people.redhat.com/jdennis/freeradius-rhel-centos/src/freeradius2-2.1.7-2.el5.src.rpm
Hi Alan,
Thanks for the advice, I've tried the same test with radiusd -f and
here are the results
Some runs just produce this:
# radiusd -f
Segmentation fault
Others produce a more verbose output, hope it helps:
# radiusd -f
*** glibc detected *** radiusd: double free or corruption (fasttop):
Hi,
I've got a freeRadius (v2.1.7) install running on CentOs using
postgresql to store accounting data and have noticed that occasionally
freeRadius seems to die unexpectedly.
After some time investigating this and going over the logs I can now
reproduce this behavior easily by following these
Duarte Fonseca wrote:
I've got a freeRadius (v2.1.7) install running on CentOs using
postgresql to store accounting data and have noticed that occasionally
freeRadius seems to die unexpectedly.
See doc/bugs. You can run the server in foreground mode (radiusd -f),
too.
If it dies after a
18 matches
Mail list logo
