fr_packet_cmp again

[Josip Almasi]

Josip Almasi wrote:
> Alan DeKok wrote:
>>
>>   Grab the "master" branch.  See http://git.freeradius.org for
>> instructions.  The internal state machine has been *completely*
>> re-written so that it's sane.  If the bug still exists there, I'll be
>> shocked.
> 
> Will try.

Died 7 mins after with
Error: ASSERT FAILED threads.c[423]: request->magic == REQUEST_MAGIC
:/

Started with -s, segfault in libfreeradius-radius-3.0.0.so.

Dang its still there!:))))
--------------------------
Program received signal SIGSEGV, Segmentation fault.
fr_packet_cmp (a=0xda9130, b=0x6e6f6b7369050d5b) at packet.c:141
141             if (a->sockfd < b->sockfd) return -1;

#0  fr_packet_cmp (a=0xda9130, b=0x6e6f6b7369050d5b) at packet.c:141
#1  0x00007ffff7bc0adb in list_find (ht=0x841840, data=0x7fffffffe158)
     at hash.c:191
#2  fr_hash_table_find (ht=0x841840, data=0x7fffffffe158) at hash.c:454
#3  0x00007ffff7bc0b29 in fr_hash_table_finddata (ht=<value optimized out>,
     data=<value optimized out>) at hash.c:484
#4  0x00007ffff7bd067a in fr_packet_list_find (pl=<value optimized out>,
     request=0xda9130) at packet.c:577
#5  0x0000000000428203 in request_receive (listener=0x858090, 
packet=0xda9130,
     client=0x7a3050, fun=0x407f60 <rad_accounting>) at process.c:1181
#6  0x0000000000415bb2 in acct_socket_recv (listener=0x858090) at 
listen.c:1382
#7  0x00000000004295ca in event_socket_handler (xel=<value optimized out>,
     fd=<value optimized out>, ctx=0x858090) at process.c:3125
#8  0x00007ffff7bd141b in fr_event_loop (el=0x841e00) at event.c:413
#9  0x000000000041d334 in main (argc=<value optimized out>,
     argv=<value optimized out>) at radiusd.c:412

(gdb) print a=0xda9130
$1 = (const RADIUS_PACKET *) 0xda9130
(gdb) print $1->sockfd
$2 = 9
(gdb) print b=0x6e6f6b7369050d5b
$3 = (const RADIUS_PACKET *) 0x6e6f6b7369050d5b
(gdb) print $3->sockfd
Cannot access memory at address 0x6e6f6b7369050d5b
--------------------------

Still running another instance of 1.2.11 under valgrind memtest, some 3M 
packets later it's still fine.

Could it be some sort of timing issue, i.e. I have faster box than you 
so you cant reproduce it?
FTR I have 16 cores, 4 x Xeon 2.8 GHz.

BTW I like what I saw in 3, response time under heavy load is way better.

Regards...