On Thu, Feb 14, 2013 at 03:17:49PM +0000, Brian Candler wrote:
I'll keep poking around, but if someone knows why the core dumps aren't being created, that would save me some time.
In switch_users(): /* * Don't do chroot/setuid/setgid if we're in debugging * as non-root. */ if (debug_flag && (getuid() != 0)) return 1; So that's why I don't see the radlog message. But if core dumps are allowed at the start, I can't see why they are being disabled. Anyway, if I run sbin/radiusd -f instead of sbin/radiusd -X then I get the core dump: 389M of it. Reading symbols for shared libraries . done Reading symbols for shared libraries .......................................................................... done #0 0x00007fff8e477df2 in select$DARWIN_EXTSN () (gdb) bt #0 0x00007fff8e477df2 in select$DARWIN_EXTSN () #1 0x000000010910efc0 in fr_event_loop (el=0x7f99e3815200) at event.c:391 #2 0x000000010907a7ad in radius_event_process () at process.c:4233 #3 0x000000010905c9b8 in main (argc=2, argv=0x7fff68c30bd8) at radiusd.c:428 (gdb) thread apply all bt Thread 6 (core thread 5): #0 0x00007fff8e4766b6 in semaphore_wait_trap () #1 0x000000010906525b in request_handler_thread (arg=0x7f99e352e010) at threads.c:567 #2 0x00007fff943628bf in _pthread_start () #3 0x00007fff94365b75 in thread_start () Thread 5 (core thread 4): #0 0x00007fff8e4766b6 in semaphore_wait_trap () #1 0x000000010906525b in request_handler_thread (arg=0x7f99e352dfd0) at threads.c:567 #2 0x00007fff943628bf in _pthread_start () #3 0x00007fff94365b75 in thread_start () Thread 4 (core thread 3): #0 0x00007fff8e4766b6 in semaphore_wait_trap () #1 0x000000010906525b in request_handler_thread (arg=0x7f99e352df90) at threads.c:567 #2 0x00007fff943628bf in _pthread_start () #3 0x00007fff94365b75 in thread_start () Thread 3 (core thread 2): #0 0x00007fff8e4766b6 in semaphore_wait_trap () #1 0x000000010906525b in request_handler_thread (arg=0x7f99e352df50) at threads.c:567 #2 0x00007fff943628bf in _pthread_start () #3 0x00007fff94365b75 in thread_start () Thread 2 (core thread 1): #0 0x00007fff94394eab in regexec () #1 0x0000000109081d01 in radius_do_cmp (request=0x7f99e352e430, presult=0x1097a4a14, lt=T_DOUBLE_QUOTED_STRING, pleft=0x1097a3dd0 "", token=T_OP_REG_EQ, rt=T_DOUBLE_QUOTED_STRING, ---Type <return> to continue, or q <return> to quit--- pright=0x1097a41e4 "ai:([0-9a-f]{32})", cflags=1, modreturn=2) at evaluate.c:393 #2 0x0000000109082e03 in radius_evaluate_condition (request=0x7f99e352e430, modreturn=2, depth=1, ptr=0x1097a4c30, evaluate_it=1, presult=0x1097a5c84) at evaluate.c:743 #3 0x000000010908241e in radius_evaluate_condition (request=0x7f99e352e430, modreturn=2, depth=0, ptr=0x1097a6960, evaluate_it=1, presult=0x1097a696c) at evaluate.c:525 #4 0x00000001090570ef in modcall (component=2, c=0x7f99e3527560, request=0x7f99e352e430) at modcall.c:468 #5 0x0000000109053fde in indexed_modcall (comp=2, idx=0, request=0x7f99e352e430) at modules.c:801 #6 0x0000000109055f29 in module_preacct (request=0x7f99e352e430) at modules.c:1666 #7 0x0000000109031b28 in rad_accounting (request=0x7f99e352e430) at acct.c:57 #8 0x000000010907223e in request_running (request=0x7f99e352e430, action=1) at process.c:1197 #9 0x000000010906553c in request_handler_thread (arg=0x7f99e352df10) at threads.c:637 #10 0x00007fff943628bf in _pthread_start () #11 0x00007fff94365b75 in thread_start () Thread 1 (core thread 0): #0 0x00007fff8e477df2 in select$DARWIN_EXTSN () #1 0x000000010910efc0 in fr_event_loop (el=0x7f99e3815200) at event.c:391 #2 0x000000010907a7ad in radius_event_process () at process.c:4233 #3 0x000000010905c9b8 in main (argc=2, argv=0x7fff68c30bd8) at radiusd.c:428 (gdb) Hmm, so it looks like thread 2. (gdb) thread 2 [Switching to thread 2 (core thread 1)] 0x00007fff94394eab in regexec () (gdb) frame 1 #1 0x0000000109081d01 in radius_do_cmp (request=0x7f99e352e430, presult=0x1097a4a14, lt=T_DOUBLE_QUOTED_STRING, pleft=0x1097a3dd0 "", token=T_OP_REG_EQ, rt=T_DOUBLE_QUOTED_STRING, pright=0x1097a41e4 "ai:([0-9a-f]{32})", cflags=1, modreturn=2) at evaluate.c:393 393 compare = regexec(®, pleft, (gdb) print reg $3 = {re_pcre = 0xf265, re_nsub = 1, re_erroffset = 0} (gdb) print pleft $4 = 0x1097a3dd0 "" (gdb) print rxmatch $5 = {{rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}, { rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}, { rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}} (gdb) Very strange: obviously regcomp succeeded, so why should regexec crash? And why not when run under gdb?? So I made a completely clean checkout and built from scratch. Exactly the same problem. Any ideas? Cheers, Brian.