segfault in current master

[Brian Candler]

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(&reg, 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.