Re: [Xenomai-help] Meassage Queue c++

Re: [Xenomai-help] Meassage Queue c++

[Stephan Zimmermann]

Am Donnerstag, 19. Januar 2006 18:04 schrieb Nathaniel Villaume:
> Hi Stephan,
>
> I don't know if it is related, but I wouldn't return a pointer to a
> local variable:
>
> void *data;
> ...
> return data;
>
> Maybe something is happening where when the queue is empty the size is 0
> --so malloc returns who-knows-what?

Hi, 
thanks for the hint, but I don't think this is the Problem, because the 
Program crashes befor the read function returns. I think it is related with 
the way I create/bind the queue in the constructor, but I am not sure.

Please don't think too much about it, I decided to stop my c++ 
realtime-experiments anyway, will code plain c instead.

Greetings, Stephan

Re: [Xenomai-help] Meassage Queue c++

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Stephan Zimmermann wrote:
> Am Donnerstag, 19. Januar 2006 18:04 schrieb Nathaniel Villaume:
>> Hi Stephan,
>>
>> I don't know if it is related, but I wouldn't return a pointer to a
>> local variable:
>>
>> void *data;
>> ...
>> return data;
>>
>> Maybe something is happening where when the queue is empty the size is 0
>> --so malloc returns who-knows-what?
> 
> Hi, 
> thanks for the hint, but I don't think this is the Problem, because the 
> Program crashes befor the read function returns. I think it is related with 
> the way I create/bind the queue in the constructor, but I am not sure.
> 
> Please don't think too much about it, I decided to stop my c++ 
> realtime-experiments anyway, will code plain c instead.

Some further things to try before giving C++ up - and maybe stumbling
over the same issue with C:

 o Did you mlockall() your program? If not, lazy-mapped pages may cause
   SEGFAULTS in the RT domain which will kill your program.

 o Does your kernel log contain any hints of Xenomai about what's going
   on?

 o Try running your program inside a debugger to catch the fault and its
   location. When your system is head-less, use gdbserver.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-help] Meassage Queue c++

[Stephan Zimmermann]

Jan Kiszka wrote:

> Some further things to try before giving C++ up - and maybe stumbling
> over the same issue with C:
I tryed out xenomai queues in plain C, works perfekt.

>  o Did you mlockall() your program? If not, lazy-mapped pages may cause
>    SEGFAULTS in the RT domain which will kill your program.
I call "mlockall(MCL_CURRENT | MCL_FUTURE);" as one of the first things in 
main();
>  o Does your kernel log contain any hints of Xenomai about what's going
>    on?
No, ist does not contain anything

>  o Try running your program inside a debugger to catch the fault and its
>    location. When your system is head-less, use gdbserver.
I tryed debugging, I singlestepped through it and learned that it crashes when 
calling rt_queue_recv(), but I can not tell why.

maybe it is because I do the "bind-thing" in the constructor, resulting in 
multiple objects of RT_QUEUE referring to the same queue.

Stephan

Re: [Xenomai-help] Meassage Queue c++

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

Stephan Zimmermann wrote:
> Jan Kiszka wrote:
> 
>> Some further things to try before giving C++ up - and maybe stumbling
>> over the same issue with C:
> I tryed out xenomai queues in plain C, works perfekt.
> 
>>  o Did you mlockall() your program? If not, lazy-mapped pages may cause
>>    SEGFAULTS in the RT domain which will kill your program.
> I call "mlockall(MCL_CURRENT | MCL_FUTURE);" as one of the first things in 
> main();
>>  o Does your kernel log contain any hints of Xenomai about what's going
>>    on?
> No, ist does not contain anything
> 
>>  o Try running your program inside a debugger to catch the fault and its
>>    location. When your system is head-less, use gdbserver.
> I tryed debugging, I singlestepped through it and learned that it crashes when 
> calling rt_queue_recv(), but I can not tell why.
> 
> maybe it is because I do the "bind-thing" in the constructor, resulting in 
> multiple objects of RT_QUEUE referring to the same queue.

But this is the idea of a queue: two users are referring to the same
object in order to communicate with each other!?

Would you mind to break out a demonstration code of your problem? Just
to check if there is some subtle Xenomai issue hidden or if it's an ugly
pitfall when using C++ in hard-RT context.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Meassage Queue c++

[Stephan Zimmermann]

> Would you mind to break out a demonstration code of your problem? Just
> to check if there is some subtle Xenomai issue hidden or if it's an ugly
> pitfall when using C++ in hard-RT context.

Can I send the 'demonstration' code as a complete eclipse managed-make project 
directly to your email address? It is a little to much (make clean && tar.gz 
~500k) to post here I think, even after a cleanup.

Stephan

Re: [Xenomai-help] Meassage Queue c++

[Stephan Zimmermann]

Hi all,
after Jan looked over my code, it turned out to be a typical self-made ( RTFM 
somehow...) problem. My code did throw an exception when rt_queue_read() 
returned a positve value different from zero (which I naturally didn't 
catch :). This caused an effect that looked like a bigger Problem.

So, after all, it turned out that it is very well possible to use Xenomai in 
C++ Projects.

Thanks for the great support, Stephan

[Xenomai-help] Meassage Queue c++

[Stephan Zimmermann]

Hello again,
still experimenting with Xenomai and C++, I did wrap a class aroud the 
rt_queue functions. This produces a suspicious bug wich I am unable to track 
down. Perhaps someone here can help.

I start two Tasks, both are instances of my Thread-class. Both Tasks call the 
constructor of my queue-class, creating an queue-object. The first one really 
creates it, the second one gets an -EEXIST error inside the constructor and 
does bind to the queue. Now both tasks have their own queue-object, 
describing the same rt_queue. (in proc everything seems good)

Now, I can write messages to the queue, wich works well. I also can read the 
queue from the other task without problems. Only if the queue is empty and 
the task attempts to read from it, my program crashes without any error- or 
log-message.

A Testprogram in plain C works well, so It must be s.th. with my C++ Classes.

Here is some Code (compiles without warnings):

Constructor:

BM_Queue::BM_Queue(const char* name, size_t size, size_t qlimit, int mode){
	name = name;
	size = size;
	qlimit = qlimit;
	mode = mode;	
	int err = rt_queue_create(&q,name,size,qlimit,mode);
	std::cout << "Constructor queue: create " << err << std::endl;
	if(err == -EEXIST){
		err = rt_queue_bind(&q,name,100000000);
		std::cout << "Konstruktor bm_queue: bind " << err << std::endl;
	}
	switch(err){
		case 0:				usecount++;
							break;
		default:				throw queue_exception(err);
							break;
	}
}


Recieve Function:

void* BM_Queue::rcv(unsigned long int timeout){	
	void* message;
	void* data;
	size_t size = rt_queue_recv(&q,&message,TM_INFINITE);	// blocking won't work!
	std::cout << "Recieve from queue: " << size << std::endl;
	if(size < 0){
		std::cout << "ERROR Q throwing exception: " << size << std::endl; 
		/*--- This exception is not thrown, it simply crashes ---*/
		throw queue_exception(size);
	}
	data = malloc(size);	//using operator new here (and delete there), does not 
change things
	memcpy(data,message,size);
	rt_queue_free(&q,message);
	return data;
}

Any Ideas?