Hi, here's the valgrind output with a backtrace (running -X): Ready to process requests. Ready to process requests. Signalled to terminate Exiting normally. ==6657== ==6657== Process terminating with default action of signal 11 (SIGSEGV) ==6657== General Protection Fault ==6657== at 0x41D988: modcallable_free (modcall.c:2237) ==6657== by 0x41D995: modcallable_free (modcall.c:2238) ==6657== by 0x41D995: modcallable_free (modcall.c:2238) ==6657== by 0x41D995: modcallable_free (modcall.c:2238) ==6657== by 0x41AB4C: indexed_modcallable_free (modules.c:308) ==6657== by 0x4E43B0C: FreeWalker (rbtree.c:63) ==6657== by 0x4E43AFD: FreeWalker (rbtree.c:61) ==6657== by 0x4E43E9C: rbtree_free (rbtree.c:74) ==6657== by 0x41AB16: virtual_server_free (modules.c:264) ==6657== by 0x41B831: virtual_servers_free (modules.c:296) ==6657== by 0x41A68C: free_mainconfig (mainconfig.c:990) ==6657== by 0x409F97: main (radiusd.c:451) ==6657== ==6657== HEAP SUMMARY: ==6657== in use at exit: 2,916,254 bytes in 34,635 blocks ==6657== total heap usage: 41,508 allocs, 6,873 frees, 3,857,039 bytes allocated ==6657== ==6657== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 1,065 of 1,345 ==6657== at 0x4C2ABED: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6657== by 0x642DB94: nss_parse_service_list (in /lib64/libc-2.15.so) ==6657== by 0x642E073: __nss_database_lookup (in /lib64/libc-2.15.so) ==6657== by 0x6AE049F: ??? ==6657== by 0x6AE0E54: ??? ==6657== by 0x63EDB2C: getgrnam_r@@GLIBC_2.2.5 (in /lib64/libc-2.15.so) ==6657== by 0x63ED14B: getgrnam (in /lib64/libc-2.15.so) ==6657== by 0x419DA7: read_mainconfig (mainconfig.c:625) ==6657== by 0x409D3E: main (radiusd.c:263) ==6657== ==6657== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 1,066 of 1,345 ==6657== at 0x4C2ABED: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6657== by 0x642DB94: nss_parse_service_list (in /lib64/libc-2.15.so) ==6657== by 0x642E073: __nss_database_lookup (in /lib64/libc-2.15.so) ==6657== by 0x6AE144F: ??? ==6657== by 0x6AE2644: ??? ==6657== by 0x63EEDEC: getpwnam_r@@GLIBC_2.2.5 (in /lib64/libc-2.15.so) ==6657== by 0x63EE78B: getpwnam (in /lib64/libc-2.15.so) ==6657== by 0x419DCE: read_mainconfig (mainconfig.c:642) ==6657== by 0x409D3E: main (radiusd.c:263) ==6657== ==6657== 340 (52 direct, 288 indirect) bytes in 1 blocks are definitely lost in loss record 1,089 of 1,345 ==6657== at 0x4C2ABED: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6657== by 0x642DB94: nss_parse_service_list (in /lib64/libc-2.15.so) ==6657== by 0x642E073: __nss_database_lookup (in /lib64/libc-2.15.so) ==6657== by 0x6AE4A16: ??? ==6657== by 0x63ECA9C: internal_getgrouplist (in /lib64/libc-2.15.so) ==6657== by 0x63ECDA9: initgroups (in /lib64/libc-2.15.so) ==6657== by 0x41A0F7: read_mainconfig (mainconfig.c:655) ==6657== by 0x409D3E: main (radiusd.c:263) ==6657== ==6657== LEAK SUMMARY: ==6657== definitely lost: 156 bytes in 3 blocks ==6657== indirectly lost: 768 bytes in 32 blocks ==6657== possibly lost: 0 bytes in 0 blocks ==6657== still reachable: 2,915,330 bytes in 34,600 blocks ==6657== suppressed: 0 bytes in 0 blocks ==6657== Reachable blocks (those to which a pointer was found) are not shown. ==6657== To see them, rerun with: --leak-check=full --show-reachable=yes ==6657== ==6657== For counts of detected and suppressed errors, rerun with: -v ==6657== Use --track-origins=yes to see where uninitialised values come from ==6657== ERROR SUMMARY: 10569 errors from 1003 contexts (suppressed: 2 from 2) ==6657== could not unlink /tmp/vgdb-pipe-from-vgdb-to-6657-by-root-on-radius-int-2 ==6657== could not unlink /tmp/vgdb-pipe-to-vgdb-from-6657-by-root-on-radius-int-2 ==6657== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-6657-by-root-on-radius-int-2 Segmentation fault On 12.10.2012 10:26, Stefan Winter wrote:
Hi,
I believe this has been reported earlier and it's not very grave, but anyway:
When shutting down the server normally, it will almost cleanly shut down, including "Exiting normally" in the logs, but will generate a SIGSEGV after that.
So, something in the terminal cleanup seems wrong. It's not a big deal usually, because after all the process is going to die anyway.
However, now with systemd, things are slightly different. systemd will watch over the return code of any PID under its responsibility and memorizes these return codes for later debugging by the admin.
So these days, I'd appreciate if even during shutdown time, things are "clean".
I looked through the shutdown in radiusd.c main() and spotted - I believe - two spots where things go wrong:
- rcode is derived from a function, and can be an arbitrary number; and the process in the end returns rcode - 1. On failures it gets set to 2 (i.e. return 1) but on normal shutdown, it doesn't get set.
I "fixed" the situation by adding a "rcode = 1" right after the "Exiting normally." This ensures that the process returns 0 once it gets to its return statement.
- It never gets there; the SIGSEGV on my system is generated during the call to free_mainconfig(). Once comment that line out, I get a clean shutdown.
I'm not sure this is a sane approach, it's rather a brute fix with the axe. Anyway, trivial patch below.
--- freeradius-server-2.2.0/src/main/radiusd.c 2012-09-10 13:51:34.000000000 +0200 +++ freeradius-server-2.2.0-patched/src/main/radiusd.c 2012-10-12 10:14:02.136026913 +0200 @@ -416,6 +416,7 @@ rcode = 2; } else { radlog(L_INFO, "Exiting normally."); + rcode = 1; }
/* @@ -448,7 +449,7 @@ /* * Free the configuration items. */ - free_mainconfig(); + /* free_mainconfig(); */
/* * Detach any modules.
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473