SIGTERM -> SIGSEGV
Stefan Winter
stefan.winter at restena.lu
Mon Oct 15 08:23:48 CEST 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20121015/9f9e1b3b/attachment.pgp>
More information about the Freeradius-Devel
mailing list