Hello,

I just had a weird case where SaClmInitialize() returned the value 0 to me. Since this value isn't valid for a enum SaAisErrorT, I investigated and I found out that corosync/coroipcc.c:coroipcc_service_connect() can return 0 in case Corosync was compiled with _POSIX_THREAD_PROCESS_SHARED <= 0 (ie on a FreeBSD system) when there is a problem with the IPC semaphores. This case is actually likely to happen on a FreeBSD system due to IPC default limits.

In the process, I also changed the way the variable 'res' was used: Since it's an enum, I've assumed it doesn't really make sense to use it to store return values of system calls, so I replaced it by sys_res.

Also, I was wondering if there could be a way to get more details when coroipcc_service_connect() fails. CS_ERR_LIBRARY and CS_ERR_TRY_AGAIN are not exactly what I would call meaningful error codes ... It's not very handy to have to try to guess if it failed because permissions on the Unix socket are wrong or because IPC limits have been reached or because an upper layer failed for some reason. I assume adding error codes like CS_ERR_SEM, CS_ERR_SHM, could be an option but letting such level of implementation details be visible in the error codes is not a valid option, right ?

Right now, when I have to diagnose this kind of issue, I'm running a patched version of Flatiron including the following macro (in lib/util.h):

+#ifdef DEBUG
+#define DPRINTX(...) do {                                            \
+     fprintf(stderr, "Corosync lib: %s:L%d: ", __FILE__, __LINE__);  \
+     fprintf(stderr, __VA_ARGS__);                                   \
+     fprintf(stderr, "\n");                                          \
+   } while (0)
+#else
+#define DPRINTX(...)
+#endif

Is there a more adequate way of getting debug information from the libraries themselves ?

I was thinking of a slightly more elegant way of doing it. I could add functions like for example: 'void coroipcc_set_lasterror(const char *str)', 'const char *coroipcc_get_lasterror(void)' ? Using pthread_setspecific(), it would be possible to make it thread-safe. Do you think it would be worth I spend some time on making a patch for that ?



Index: lib/coroipcc.c
===================================================================
--- lib/coroipcc.c	(révision 2739)
+++ lib/coroipcc.c	(copie de travail)
@@ -654,42 +654,42 @@
 		goto error_connect;
 	}
 
-	res = memory_map (
+	sys_res = memory_map (
 		control_map_path,
 		"control_buffer-XXXXXX",
 		(void *)&ipc_instance->control_buffer,
 		8192);
-	if (res == -1) {
+	if (sys_res == -1) {
 		res = CS_ERR_LIBRARY;
 		goto error_connect;
 	}
 
-	res = memory_map (
+	sys_res = memory_map (
 		request_map_path,
 		"request_buffer-XXXXXX",
 		(void *)&ipc_instance->request_buffer,
 		request_size);
-	if (res == -1) {
+	if (sys_res == -1) {
 		res = CS_ERR_LIBRARY;
 		goto error_request_buffer;
 	}
 
-	res = memory_map (
+	sys_res = memory_map (
 		response_map_path,
 		"response_buffer-XXXXXX",
 		(void *)&ipc_instance->response_buffer,
 		response_size);
-	if (res == -1) {
+	if (sys_res == -1) {
 		res = CS_ERR_LIBRARY;
 		goto error_response_buffer;
 	}
 
-	res = circular_memory_map (
+	sys_res = circular_memory_map (
 		dispatch_map_path,
 		"dispatch_buffer-XXXXXX",
 		(void *)&ipc_instance->dispatch_buffer,
 		dispatch_size);
-	if (res == -1) {
+	if (sys_res == -1) {
 		res = CS_ERR_LIBRARY;
 		goto error_dispatch_buffer;
 	}
@@ -718,18 +718,21 @@
 		 * an existing shared memory segment for which we have access
 		 */
 		if (errno != EEXIST && errno != EACCES) {
+			res = CS_ERR_LIBRARY;
 			goto error_exit;
 		}
 	}
 
 	semun.val = 0;
-	res = semctl (ipc_instance->semid, 0, SETVAL, semun);
-	if (res != 0) {
+	sys_res = semctl (ipc_instance->semid, 0, SETVAL, semun);
+	if (sys_res != 0) {
+		res = CS_ERR_LIBRARY;
 		goto error_exit;
 	}
 
-	res = semctl (ipc_instance->semid, 1, SETVAL, semun);
-	if (res != 0) {
+	sys_res = semctl (ipc_instance->semid, 1, SETVAL, semun);
+	if (sys_res != 0) {
+		res = CS_ERR_LIBRARY;
 		goto error_exit;
 	}
 #endif
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais

Reply via email to