Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Occasional crash with 3.0.19 #2732

pauldekkers opened this issue Jun 6, 2019 · 2 comments


None yet
2 participants
Copy link

commented Jun 6, 2019

Issue type

  • Defect - Crash or memory corruption.


How to reproduce the issue

There's no trigger I'm aware of, or no special configuration. It just happens after a couple of weeks. It does happen occasionally. It happened with earlier releases too, I never got to capturing the event: but now I have a core dump :-)

(While it happened with earlier releases, somewhere above 3.0.15 I think, the exact same configuration did run without issues somewhere in the past. And while this is a busy server, the crashes are really occasional.)

I'm using the 3.0.19 docker container these days, on an Ubuntu 18.04 LTS host. (Previously it crashed with self-compiled releases and no containers too.) Looking at system graphs, I see no issues with resources (memory, disk spikes) whatsoever at the time of the crash. (It was actually at a quiet time, in the middle of the night).

This is a proxy server (it does no EAP, just RADIUS/UDP and TLS, sqlite and rlm_cache_rbtree).

Full backtrace from LLDB or GDB

# gdb /usr/sbin/freeradius /tmp/core.1
GNU gdb (Ubuntu 8.1-0ubuntu3)
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/freeradius...Reading symbols from /usr/lib/debug/.build-id/34/960d4eec3b9f81521a5e219541668773d33c98.debug...done.
[New LWP 86]
[New LWP 88]
[New LWP 1]
[New LWP 92]
[New LWP 85]
[New LWP 90]
[New LWP 84]
[New LWP 87]
[New LWP 89]
[New LWP 83]
[New LWP 91]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/".
Core was generated by `freeradius -f -d /etc/freeradius'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
[Current thread is 1 (Thread 0x7f65b17fa700 (LWP 86))]
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000560a22119575 in request_handler_thread (arg=0x560a257ccc60) at src/main/threads.c:826
#2  0x00007f65e913b6db in start_thread (arg=0x7f65b17fa700) at pthread_create.c:463
#3  0x00007f65e89ae88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Hope this gives some direction to look at. If there's a new event (hopefully similar) I'll add it to this issue, but for this crash I was already waiting for over 6 weeks. (And before that, core dumps were not happening for various reasons.)

jpereira added a commit to jpereira/freeradius-server that referenced this issue Jun 7, 2019

jpereira added a commit to jpereira/freeradius-server that referenced this issue Jun 7, 2019

jpereira added a commit to jpereira/freeradius-server that referenced this issue Jun 7, 2019


This comment has been minimized.

Copy link

commented Jun 12, 2019

@jpereira just checking; none of your patches ended up in a PR, right?


This comment has been minimized.

Copy link

commented Jun 12, 2019

@pauldekkers exactly. Alan mentioned some good points and it needs more investigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.