Segmentation Fault of Server

1 
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::127) SIGSEGV received, aborting Aerospike Community Edition build 3.4.1
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 0: /usr/bin/asd(as_sig_handle_segv+0x59) [0x46b5b4]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 1: /lib64/libc.so.6(+0x34950) [0x7fdbb28a1950]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 2: /usr/bin/asd(cf_dyn_buf_append_string+0x1f) [0x4f6512]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 3: /usr/bin/asd(info_get_service+0x13) [0x47d39d]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 4: /usr/bin/asd(info_some+0x21d) [0x48022b]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 5: /usr/bin/asd(thr_info_fn+0x297) [0x48070a]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 6: /lib64/libpthread.so.0(+0x752a) [0x7fdbb377252a]
Feb 17 2015 19:00:45 GMT: WARNING (as): (signal.c::129) stacktrace: frame 7: /lib64/libc.so.6(clone+0x6d) [0x7fdbb296d79d]
2

Jakub_Jozwicki,

Did you see this immediately after ther server was started. If yes there could be possible race condition where thread which sets up information being accessed by info_get_service may not have been initialized. If no then can you please share service section of aerospike.conf you are running with.

Thanks for reporting bug. This will be fixed.

– R

3

This was in the 2nd hour of stress tests. Configuration bases on default.

service {
 [...]
 service-threads 4
 transaction-queues 4
 transaction-threads-per-queue 4
 transaction-max-ms 10000
 proto-fd-max 15000
}
4

Found this one as well. Will be fixed … :smile:

thanks – R

1 Like
5

info_node_info_reduce_fn(void *key, void *data, void *udata) is written badly:

cf_debug uses g_service_str without synchronization (string can be during cf_free or strdup), also there is return(-1) without releasing mutex;

info_get_service is missing obvious pthread_mutex_lock(&g_service_lock) + pthread_mutex_unlock(&g_service_lock);

6

Your observation is correct. This has been fixed :smile:

– R

1 Like