I've been trying to pin down a rather elusive segfault for over 2 months now. and i finally got it to happen inside of gdb. this is freeradius 1.1.6, on rhel5 x86-64 if this problem is fixed in 2.0 or 1.1.7 please let me know. Starting program: /usr/sbin/radiusd -X [Thread debugging using libthread_db enabled] [New Thread 46912543318400 (LWP 8450)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912543318400 (LWP 8450)] 0x00002aaaac1666d5 in _int_malloc () from /lib64/libc.so.6 * 1 Thread 46912543318400 (LWP 8450) 0x00002aaaac1666d5 in _int_malloc () from /lib64/libc.so.6 Thread 1 (Thread 46912543318400 (LWP 8450)): #0 0x00002aaaac1666d5 in _int_malloc () from /lib64/libc.so.6 No symbol table info available. #1 0x00002aaaac167d4d in malloc () from /lib64/libc.so.6 No symbol table info available. #2 0x00002aaaabe05102 in CRYPTO_malloc () from /lib64/libcrypto.so.6 No symbol table info available. #3 0x00002aaaabe2a6b7 in BN_free () from /lib64/libcrypto.so.6 No symbol table info available. #4 0x00002aaaabe2a808 in bn_expand2 () from /lib64/libcrypto.so.6 No symbol table info available. #5 0x00002aaaabe2abd5 in BN_bin2bn () from /lib64/libcrypto.so.6 No symbol table info available. #6 0x00002aaaabe36ea0 in RSA_PKCS1_SSLeay () from /lib64/libcrypto.so.6 No symbol table info available. #7 0x00002aaaabb7cc62 in ssl3_get_client_key_exchange () from /lib64/libssl.so.6 No symbol table info available. #8 0x00002aaaabb7ecaf in ssl3_accept () from /lib64/libssl.so.6 No symbol table info available. #9 0x00002aaaabb854c3 in ssl3_read_bytes () from /lib64/libssl.so.6 No symbol table info available. #10 0x00002aaaabb82431 in ssl3_renegotiate_check () from /lib64/libssl.so.6 No symbol table info available. #11 0x00002aaaae1d77da in tls_handshake_recv (ssn=0x555558718240) at tls.c:173 err = <value optimized out> #12 0x00002aaaae1d6ad5 in eaptls_process (handler=0x555559e07860) at eap_tls.c:638 tls_session = (tls_session_t *) 0x555558718240 tlspacket = (EAPTLS_PACKET *) 0x55555860bc80 status = EAPTLS_LENGTH_INCLUDED #13 0x00002aaaaebe642b in eappeap_authenticate (arg=0x5555584e9ac0, handler=0x555559e07860) at rlm_eap_peap.c:169 rcode = <value optimized out> status = <value optimized out> tls_session = (tls_session_t *) 0x555558718240 #14 0x00002aaaadfcf1c6 in eaptype_call (atype=0x5555584e7d50, handler=0x555559e07860) at eap.c:167 rcode = <value optimized out> #15 0x00002aaaadfcf30a in eaptype_select (inst=0x5555584d23d0, handler=0x555559e07860) at eap.c:361 default_eap_type = <value optimized out> eaptype = (eaptype_t *) 0x555559d5feb8 vp = <value optimized out> namebuf = "\000\000\000\000\000\000\000\000@ÒoXUU\000\000P®oXUU\000\000\237æüª*\000\000àßoXUU\000\000xF\035®ª*\000\000\000\000\000\000\000\000Ð\000XLwUUU\000" eaptype_name = 0x2aaaae1d7d26 "peap" #16 0x00002aaaadfcdffb in eap_authenticate (instance=0x5555584d23d0, request=0x555558609f90) at rlm_eap.c:261 inst = (rlm_eap_t *) 0x2aaaac442960 handler = (EAP_HANDLER *) 0x555559e07860 eap_packet = (eap_packet_t *) 0x0 rcode = <value optimized out> #17 0x0000555555563682 in modcall (component=0, c=0x5555584cfe30, request=0x555558609f90) at modcall.c:236 myresult = 0 #18 0x0000555555563c71 in call_one (component=-1404819104, p=0x80, request=0x55555860b0e0, priority=0x2aaaac442ad0, result=0x400000) at modcall.c:269 r = <value optimized out> #19 0x000055555556384c in modcall (component=0, c=0x5555584cfe80, request=0x555558609f90) at modcall.c:324 g = (modgroup *) 0x5555584cfe80 myresult = 0 #20 0x000055555555b763 in rad_check_password (request=0x555558609f90) at auth.c:380 dval = (DICT_VALUE *) 0x0 auth_type_pair = <value optimized out> cur_config_item = <value optimized out> password_pair = (VALUE_PAIR *) 0x0 auth_item = <value optimized out> string = "à[oÑÿ\177\000\000@foÑÿ\177\000\000\020ºUUUU\000\000\220÷VUUU\000\000ÀÜ:XUU\000\000LíVUUU\000\0008ö\a\000\000\000\000\000uest 521P\031OXUU\000\000ç6VUUU\000\000\220\237`XUU\000\000\000\020\000\000\002\000\000\000\200ázª*\000\000\000\000\000\000\000\000ÿÿö\003\000\000\030\000\000\000P(OXUU\000\000Ä\\oÑÿ\177\000\000À\\oÑÿ\177\000\000\001\000\000\000\000\000\000\000\220\237`XUU\000\000P\031OXUU\000\000q<VUUU\000\000P(OXUU\000\000P\031OXUU\000\000Ä\\oÑÿ\177\000\000"... auth_type = 6 result = <value optimized out> auth_type_count = 1 #21 0x000055555555bc8a in rad_authenticate (request=0x555558609f90) at auth.c:675 check_item = <value optimized out> vp = (VALUE_PAIR *) 0x55555860b0e0 namepair = (VALUE_PAIR *) 0x5555586c89d0 check_item = <value optimized out> reply_item = <value optimized out> auth_item = (VALUE_PAIR *) 0x0 module_msg = <value optimized out> tmp = (VALUE_PAIR *) 0x0 result = 3 r = <value optimized out> umsg = "P\"lXUU\000\000P\"lXUU\000\000\020\000\000\000\000\000\000\000³\004\026¬ª*\000\000Ø\237`XUU\000\000`\027D¬ª*\000\000<\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\000`¬ªª*\000\000Æ\003\026¬ª*\000\000\020\000\000\000\000\000\000\000`\027D¬ª*\000\000`\027D¬ª*\000\000\n\000\000\000\000\000\000\000ì,pXUU\000\000¡\2101«ª*\000\000P\035D¬ª*\000\000P\"lXUU\000\000\214\"lXUU\000\000ì,pXUU\000\000\020\000\000\000\000\000\000\0005´1«ª*\000\000Ø\237`XUU\000\000\000\000\000\000\000\000\000\000\020LiXUU\000\000"... user_msg = <value optimized out> exec_program = <value optimized out> exec_wait = <value optimized out> seen_callback_id = <value optimized out> buf = "fc4daac0ccb383c13719d6ce6b49e659e4ef4a89709757b2585190f69bb3d66c\030\000\000\0000\000\000\000ÀdoÑÿ\177\000\000\000doÑÿ\177\000\0000c69140301000101160301003074a66566d27123ef7e02bd329e6e670027d85e69ca060d2f22ca38b096596f7d3dc57f7230c750ff8a4c50"... logstr = "\020\000\000\0000\000\000\000\001\000\000\000\000\000\000\000\020\000\000\0000\000\000\000P`oÑÿ\177\000\000\220_oÑÿ\177\000\000ù\034¦N\bú\206\035/&ç°Q&\235½í©|ÉgÃ:Oê@è\004¤}éæþ·¤ó<?C\177³5ø\003y\206¿h¯\017\000\000\202\000\200 Ã\020ñû#ëÓ]iðÀ\030ÃÓBª{\000\tiÅ8\205\214Óä¹\227ôfq³\200wûä¶mª\0223¡,¥´Äq]?ïE\002/á\0013\020^oÑÿ\177\000\000\000\000\000\000\000\000\000\000OdoÑÿ\177\000\000P`oÑÿ\177\000\000P`oÑÿ\177\000\000p_oÑÿ\177\000\000"... autz_retry = <value optimized out> autz_type = <value optimized out> #22 0x0000555555564bfa in rad_respond (request=0x555558609f90, fun=0x55555555ba10 <rad_authenticate>) at radiusd.c:1669 rcode = 0 packet = <value optimized out> original = <value optimized out> secret = 0x555558609fd8 "stupid" finished = <value optimized out> reprocess = <value optimized out> #23 0x00005555555661d6 in main (argc=<value optimized out>, argv=<value optimized out>) at radiusd.c:1434 fun = (RAD_REQUEST_FUNP) 0x55555555ba10 <rad_authenticate> request = (REQUEST *) 0x555558609f90 packet = (RADIUS_PACKET *) 0x555558694c10 secret = (u_char *) 0x5555584cc6f8 "stupid" buffer = "10.13.13.13\000\000\000\000\000«Hؼ`\016a*ä2Ý«ª*\000\000ðwoÑÿ\177\000\000x²\r¬ª*\000\000\000\000\000\000\000\000\000\000àjoÑÿ\177\000\000\002\000\000\000\000\000\000\000°ioÑÿ\177\000\000\213}«ªª*\000\000\000¶uª¹\215ñ\016ìò*Ä\223v\001\001\200woÑÿ\177\000\000ðwoÑÿ\177\000\000p\215Ú«ª*\000\000\000\000\000\000\000\000\000\000ÀloÑÿ\177\000\000\a\000\000\000\000\000\000\000½`«ªª*\000\000\000\000\000\000\000\000\000\000`\215Ú«ª*\000\000\000\000\000\000\000\000\000\000¦}«ªª*\000\000\200woÑÿ\177\000\000"... readfds = {fds_bits = {128, 0 <repeats 15 times>}} argval = <value optimized out> pid = <value optimized out> max_fd = <value optimized out> status = <value optimized out> tv = (struct timeval *) 0x2 act = {__sigaction_handler = {sa_handler = 0x5555555649e0 <sig_fatal>, sa_sigaction = 0x5555555649e0 <sig_fatal>}, sa_mask = {__val = { 0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0} listener = <value optimized out> The program is running. Exit anyway? (y or n) Not confirmed. thanks, joe
Joe Vieira wrote:
I've been trying to pin down a rather elusive segfault for over 2 months now. and i finally got it to happen inside of gdb.
this is freeradius 1.1.6, on rhel5 x86-64
if this problem is fixed in 2.0 or 1.1.7 please let me know.
Since we have no idea what the problem is, the answer is likely "no". ...
Thread 1 (Thread 46912543318400 (LWP 8450)): #0 0x00002aaaac1666d5 in _int_malloc () from /lib64/libc.so.6 No symbol table info available.
If malloc() is core dumping, then something else is going wrong. i.e. some other part of the server is over-writing memory. ..
#11 0x00002aaaae1d77da in tls_handshake_recv (ssn=0x555558718240) at tls.c:173 err = <value optimized out>
For debugging, you should probably build the server without using -O flags. That way, all of the information will be available to gdb. I would try 2.0. Large amounts of code have been re-written or updated. It may not be perfect, but there are good odds that this problem won't re-appear. Alan DeKok.
Since we have no idea what the problem is, the answer is likely "no".
totally fair =)
If malloc() is core dumping, then something else is going wrong. i.e. some other part of the server is over-writing memory.
when you say "the server" i assume you mean freeradius not another app.??
I would try 2.0. Large amounts of code have been re-written or updated. It may not be perfect, but there are good odds that this problem won't re-appear.
that's what i'll do then. thanks for the help, Joe
Hi,
If malloc() is core dumping, then something else is going wrong. i.e. some other part of the server is over-writing memory.
when you say "the server" i assume you mean freeradius not another app.??
no - i'd read that as some other part of your 64bit x86 box is trashing the memory. hyperthreading on? alan
no - i'd read that as some other part of your 64bit x86 box is trashing the memory. hmm, the box itself is totally stable, nothing else has been an issue... hyperthreading on? no they are true dualcore Xeon's w/ no hyperthreading. Joe
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Joe Vieira