[Openais] [patch] saEvtDispatch seg fault

Hegde, Ramesh (STSD) rameshh at hp.com
Sun Aug 12 21:35:13 PDT 2007


Hello,

Is it appropriate to handle this part in Initialize? The dispatch part
in meaningful only for the consumer or subscriber part. In case the
initialization is for the purpose of producing the Events, then this
memory allocation may be not required at all.

Also, when we invoke this in java using JNI , by default the memory per
thread in Java is 256kb which may not be sufficient again irrespective
of whether we allocate in dispatch or initialize. My preference is to
allocate this on heap on dispatch.

Regards
Ramesh

-----Original Message-----
From: openais-bounces at lists.linux-foundation.org
[mailto:openais-bounces at lists.linux-foundation.org] On Behalf Of Steven
Dake
Sent: Saturday, August 11, 2007 8:39 AM
To: Russell Bryant
Cc: openais at lists.linux-foundation.org
Subject: Re: [Openais] [patch] saEvtDispatch seg fault

Russell & Ramesh,

Somehow this fell off my todo list.  What is really needed here is that
the dispatch buffer is allocated in saEvtInitialize instead of
saEvtDispatch.  This way the appropriate error code may be returned in
saEvtInitialize instead of the improper SA_AIS_ERR_LIBRARY being
returned in saEvtDispatch.

The initialize function should initialize any data areas needed for
operation for APIs that cannot return SA_AIS_ERR_NO_MEMORY.

If you want to modify your patch to do that it would be much appreciated
- or I should get to it at some point in the future after my current
plate of bugs clears up.

This should be done for all APIs since it appears the dispatch thread is
often created with a stack size less then the required 1.1mb.

Regards
-steve


On Thu, 2007-08-09 at 17:46 -0500, Russell Bryant wrote:
> Russell Bryant wrote:
> > Program terminated with signal 11, Segmentation fault.
> > #0  0xb6c5ac23 in saEvtDispatch (evtHandle=Cannot access memory at
address
> >        0xb6b572a0 ) at evt.c:591
> > 591     {
> 
> Fixed!
> 
> The problem was that the saEvtDispatch() function was allocating a 
> structure on the stack with a size of about 1 MB.  However, the 
> threads in this application are created with relatively small stack
sizes.
> 
> I have attached a patch that makes this code work for me.  It changes 
> this massive struct to be allocated on the heap instead of the stack.
> 
> The patch was made against the whitetank branch.
> 
> plain text document attachment (evt_stack.rev1.txt)
> Index: lib/evt.c
> ===================================================================
> --- lib/evt.c	(revision 1409)
> +++ lib/evt.c	(working copy)
> @@ -599,7 +599,7 @@
>  	int ignore_dispatch = 0;
>  	int cont = 1; /* always continue do loop except when set to 0 */
>  	int poll_fd;
> -	struct res_overlay dispatch_data;
> +	struct res_overlay *dispatch_data;
>  	struct lib_event_data *evt = 0;
>  	struct res_evt_event_data res;
>  
> @@ -621,6 +621,10 @@
>  		timeout = 0;
>  	}
>  
> +	dispatch_data = malloc(sizeof (*dispatch_data));
> +	if (!dispatch_data)
> +		return SA_AIS_ERR_LIBRARY;
> +
>  	do {
>  		poll_fd = evti->ei_dispatch_fd;
>  
> @@ -674,15 +678,15 @@
>  			}
>  
>  			if (ufds.revents & POLLIN) {
> -				error = saRecvRetry
(evti->ei_dispatch_fd, &dispatch_data.header,
> +				error = saRecvRetry
(evti->ei_dispatch_fd, 
> +&dispatch_data->header,
>  					sizeof (mar_res_header_t));
>  
>  				if (error != SA_AIS_OK) {
>  					goto dispatch_unlock;
>  				}
> -				if (dispatch_data.header.size > sizeof
(mar_res_header_t)) {
> -					error = saRecvRetry
(evti->ei_dispatch_fd, &dispatch_data.data,
> -
dispatch_data.header.size - sizeof (mar_res_header_t));
> +				if (dispatch_data->header.size > sizeof
(mar_res_header_t)) {
> +					error = saRecvRetry
(evti->ei_dispatch_fd, &dispatch_data->data,
> +
dispatch_data->header.size - sizeof (mar_res_header_t));
>  					if (error != SA_AIS_OK) {
>  						goto dispatch_unlock;
>  					}
> @@ -697,7 +701,7 @@
>  			 * Fake up a header message and the switch
statement will
>  			 * take care of the rest.
>  			 */
> -			dispatch_data.header.id =
MESSAGE_RES_EVT_AVAILABLE;
> +			dispatch_data->header.id =
MESSAGE_RES_EVT_AVAILABLE;
>  		}
>  
>  		/*
> @@ -713,7 +717,7 @@
>  		/*
>  		 * Dispatch incoming response
>  		 */
> -		switch (dispatch_data.header.id) {
> +		switch (dispatch_data->header.id) {
>  
>  		case MESSAGE_RES_EVT_AVAILABLE:
>  			evti->ei_data_available = 0;
> @@ -782,7 +786,7 @@
>  		case MESSAGE_RES_EVT_CHAN_OPEN_CALLBACK:
>  		{
>  			struct res_evt_open_chan_async *resa = 
> -				(struct res_evt_open_chan_async
*)&dispatch_data;
> +				(struct res_evt_open_chan_async
*)dispatch_data;
>  			struct event_channel_instance *eci;
>  
>  			/*
> @@ -815,7 +819,7 @@
>  			break;
>  
>  		default:
> -			DPRINT (("Dispatch: Bad message type 0x%x\n",
dispatch_data.header.id));
> +			DPRINT (("Dispatch: Bad message type 0x%x\n", 
> +dispatch_data->header.id));
>  			error = SA_AIS_ERR_LIBRARY;	
>  			goto dispatch_put;
>  		}
> @@ -857,6 +861,7 @@
>   			pthread_mutex_unlock(&evti->ei_dispatch_mutex);
>  dispatch_put:
>  	saHandleInstancePut(&evt_instance_handle_db, evtHandle);
> +	free(dispatch_data);
>  	return error;
>  }
>  
> _______________________________________________
> Openais mailing list
> Openais at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais

_______________________________________________
Openais mailing list
Openais at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais



More information about the Openais mailing list