[Xenomai-help] Does Valgrind work with Xenomai?

[Xenomai-help] Does Valgrind work with Xenomai?

[Robert McCullough]

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

Hi,

 

I currently have a C++ application that is using 5 RTDM drivers, 2 Xenomai
real-time user-space threads and several non-real-time Linux threads.

This application seems to have a memory leak because after running for
several hours the OOM-Killer kills this application.

I am looking for a memory leak detection tool to help find the leak.

  

Two years ago in the following mail it was mentioned that making Valgrind
aware of Xenomai syscalls was on the todo list.

http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805

 

Has this been done?

Does Valgrind work with Xenomai?

Do you have to use the Xenomai simulator with Valgrind?

Or is there a better memory debugger the works with C++, Linux, and Xenomai?

 

Thanks, 

Rob


[-- Attachment #2: Type: text/html, Size: 3830 bytes --]

Re: [Xenomai-help] Does Valgrind work with Xenomai?

[Philippe Gerum]

Robert McCullough wrote:
> Hi,
> 
>  
> 
> I currently have a C++ application that is using 5 RTDM drivers, 2
> Xenomai real-time user-space threads and several non-real-time Linux
> threads.
> 
> This application seems to have a memory leak because after running for
> several hours the OOM-Killer kills this application.
> 
> I am looking for a memory leak detection tool to help find the leak.
> 
>   
> 
> Two years ago in the following mail it was mentioned that making
> Valgrind aware of Xenomai syscalls was on the todo list.
> 
> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
> 
>  
> 
> Has this been done?
>

No news.

> Does Valgrind work with Xenomai?
> 

Nope.

> Do you have to use the Xenomai simulator with Valgrind?
> 

This won't work in your case. The simulator is rather aimed at virtualizing a
standalone environment for debugging the nucleus and skins that normally run in
kernel space; it is not application-oriented - you would have lots of namespace
conflicts to begin with.

> Or is there a better memory debugger the works with C++, Linux, and Xenomai?
> 

Sorry for the lame suggestion, but you may have to resort to old cranky tools
like dmalloc, provided your new/delete operators are still backed by malloc(3).
At least you should be able to identify some leakage.

>  
> 
> Thanks, 
> 
> Rob
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.

Re: [Xenomai-help] Does Valgrind work with Xenomai?

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Robert McCullough wrote:
>> Hi,
>>
>>
>>
>> I currently have a C++ application that is using 5 RTDM drivers, 2
>> Xenomai real-time user-space threads and several non-real-time Linux
>> threads.
>>
>> This application seems to have a memory leak because after running for
>> several hours the OOM-Killer kills this application.
>>
>> I am looking for a memory leak detection tool to help find the leak.
>>
>>
>>
>> Two years ago in the following mail it was mentioned that making
>> Valgrind aware of Xenomai syscalls was on the todo list.
>>
>> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
>>
>>
>>
>> Has this been done?
>>
>
> No news.
>
>> Does Valgrind work with Xenomai?
>>
>
> Nope.

Another way around, at least if you are using the posix skin, is to
compile your application for Linux without Xenomai. If you are using a
legacy API, you can do this with Xenomai/SOLO. If you are using the native
API, then maybe you can ask gently Philippe to write a native skin for
Xenomai/SOLO.

Now, about valgrind, I spent some time thinking about it. A first
modification of valgrind, is to allow dynamic syscall tables, such as what
Xenomai use. This should be an easy task.

The next task is to rewrite all xenomai syscalls in valgrind language
(that is mainly to identify memory reads and writes), this is not a hard
task, but a rather long one. So, my idea (which remains an idea for now)
was to write the interface of the syscalls in IDL, and to generate
automatically the code for valgrind.

-- 
                    Gilles.

Re: [Xenomai-help] Does Valgrind work with Xenomai?

[stephane ancelot]

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

wLe Thu, 20 Nov 2008 14:24:30 +0100, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> a écrit:

>
> Philippe Gerum wrote:
>> Robert McCullough wrote:
>>> Hi,
>>>
>>>
>>>
>>> I currently have a C++ application that is using 5 RTDM drivers, 2
>>> Xenomai real-time user-space threads and several non-real-time Linux
>>> threads.
>>>
>>> This application seems to have a memory leak because after running for
>>> several hours the OOM-Killer kills this application.
>>>
>>> I am looking for a memory leak detection tool to help find the leak.
>>>
>>>
>>>
>>> Two years ago in the following mail it was mentioned that making
>>> Valgrind aware of Xenomai syscalls was on the todo list.
>>>
>>> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
>>>
>>>
>>>
>>> Has this been done?
>>>
>>
>> No news.
>>
>>> Does Valgrind work with Xenomai?
>>>
>>
>> Nope.
>
> Another way around, at least if you are using the posix skin, is to
> compile your application for Linux without Xenomai. If you are using a
> legacy API, you can do this with Xenomai/SOLO. If you are using the  
> native
> API, then maybe you can ask gently Philippe to write a native skin for
> Xenomai/SOLO.
>
> Now, about valgrind, I spent some time thinking about it. A first
> modification of valgrind, is to allow dynamic syscall tables, such as  
> what
> Xenomai use. This should be an easy task.
>
> The next task is to rewrite all xenomai syscalls in valgrind language
> (that is mainly to identify memory reads and writes), this is not a hard
> task, but a rather long one. So, my idea (which remains an idea for now)
> was to write the interface of the syscalls in IDL, and to generate
> automatically the code for valgrind.
>


I would tell, no , it does not ... after spending time with it .

enclosed is a patch of my work against valgrind 3.3.0


Best Regards
Steph

[-- Attachment #2: valgrind-3.3.0patch.txt --]
[-- Type: text/plain, Size: 4035 bytes --]

diff -uNr -x '*supp' -x '*html' -x '*txt' -x vg_regtest -x vg_perf -x libvex_guest_offsets.h -x genoffsets ./coregrind/m_syswrap/syswrap-linux.c ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-linux.c
--- ./coregrind/m_syswrap/syswrap-linux.c	2007-12-11 00:18:43.000000000 +0100
+++ ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-linux.c	2008-05-21 14:55:59.338660493 +0200
@@ -2797,6 +2797,7 @@
    }
 }
 
+
 /* ---------------------------------------------------------------------
    ioprio_ wrappers
    ------------------------------------------------------------------ */
@@ -2822,6 +2823,9 @@
       PRE_MEM_READ( "utimensat(tvp)", ARG3, sizeof(struct vki_timespec) );
 }
 
+
+
+
 #undef PRE
 #undef POST
 
diff -uNr -x '*supp' -x '*html' -x '*txt' -x vg_regtest -x vg_perf -x libvex_guest_offsets.h -x genoffsets ./coregrind/m_syswrap/syswrap-x86-linux.c ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-x86-linux.c
--- ./coregrind/m_syswrap/syswrap-x86-linux.c	2007-12-11 00:18:43.000000000 +0100
+++ ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-x86-linux.c	2008-05-21 15:44:59.578280281 +0200
@@ -788,6 +788,8 @@
 DECL_TEMPLATE(x86_linux, sys_vm86old);
 DECL_TEMPLATE(x86_linux, sys_vm86);
 DECL_TEMPLATE(x86_linux, sys_syscall223);
+DECL_TEMPLATE(x86_linux, xeno_bind_skin);
+DECL_TEMPLATE(x86_linux, xn_shadow_sys_info);
 
 PRE(old_select)
 {
@@ -1816,6 +1818,26 @@
                                       ARG4, ARG5, ARG6 );
 }
 
+PRE(xeno_bind_skin)
+{
+  PRINT("skin pre");
+}
+
+POST(xeno_bind_skin)
+{
+  PRINT("rt_skin_bind pre");
+}
+PRE(xn_shadow_sys_info)
+{
+  PRINT("xn_shadow_sys_info");
+}
+
+POST(xn_shadow_sys_info)
+{
+  PRINT("xn_shadow_sys_info");
+}
+
+
 #undef PRE
 #undef POST
 
@@ -1827,8 +1849,18 @@
 /* Add an x86-linux specific wrapper to a syscall table. */
 #define PLAX_(sysno, name)    WRAPPER_ENTRY_X_(x86_linux, sysno, name) 
 #define PLAXY(sysno, name)    WRAPPER_ENTRY_XY(x86_linux, sysno, name)
-
-
+/* Xenomai multiplexer syscall. */
+#define __xn_sys_mux        555	/* Must fit within 15bit */
+/* Xenomai nucleus syscalls. */
+#define __xn_sys_bind       0	/* muxid = bind_to_interface(magic,featdep,abirev) */
+#define __xn_sys_completion 1	/* xnshadow_completion(&completion) */
+#define __xn_sys_migrate    2	/* switched = xnshadow_relax/harden() */
+#define __xn_sys_barrier    3	/* started = xnshadow_wait_barrier(&entry,&cookie) */
+#define __xn_sys_info       4	/* xnshadow_get_info(muxid,&info) */
+#define __xn_sys_arch       5	/* r = xnarch_local_syscall(args) */
+#define __xn_sys_trace      6	/* r = xntrace_xxx(...) */
+#define __xn_mux_code(shifted_id,op) ((op << 24)|shifted_id|(__xn_sys_mux & 0x7fff))
+#define XENOMAI_SYSCALL(op) __xn_mux_code(0,op)
 // This table maps from __NR_xxx syscall numbers (from
 // linux/include/asm-i386/unistd.h) to the appropriate PRE/POST sys_foo()
 // wrappers on x86 (as per sys_call_table in linux/arch/i386/kernel/entry.S).
@@ -2218,6 +2250,9 @@
    LINXY(__NR_get_robust_list,	 sys_get_robust_list),  // 312
 
    LINX_(__NR_utimensat,         sys_utimensat),        // 320
+//   LINXY(__xn_sys_mux,         rt_heap_bind),        // 555
+   PLAXY(__xn_sys_mux,           xeno_bind_skin),        // 555
+   PLAXY(XENOMAI_SYSCALL(__xn_sys_info),xn_shadow_sys_info),        
 };
 
 const UInt ML_(syscall_table_size) = 
diff -uNr -x '*supp' -x '*html' -x '*txt' -x vg_regtest -x vg_perf -x libvex_guest_offsets.h -x genoffsets ./include/vki/vki-scnums-x86-linux.h ../../valgrind-3.3.0/include/vki/vki-scnums-x86-linux.h
--- ./include/vki/vki-scnums-x86-linux.h	2007-12-11 00:18:25.000000000 +0100
+++ ../../valgrind-3.3.0/include/vki/vki-scnums-x86-linux.h	2008-05-16 16:15:34.286985343 +0200
@@ -353,6 +353,8 @@
 #define __NR_vmsplice		316
 #define __NR_utimensat		320
 
+#define __xn_sys_mux            555
+
 #endif /* __VKI_SCNUMS_X86_LINUX_H */
 
 /*--------------------------------------------------------------------*/

Re: [Xenomai-help] Does Valgrind work with Xenomai?

[Robert McCullough]

  --> -----Original Message-----
  --> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
  --> Sent: Thursday, November 20, 2008 8:25 AM
  --> To: rpm@xenomai.org
  --> Cc: rob@domain.hid; xenomai@xenomai.org
  --> Subject: Re: [Xenomai-help] Does Valgrind work with Xenomai?
  --> 
  --> 
  --> Philippe Gerum wrote:
  --> > Robert McCullough wrote:
  --> >> Hi,
  --> >>
  --> >>
  --> >>
  --> >> I currently have a C++ application that is using 5 RTDM drivers, 2
  --> >> Xenomai real-time user-space threads and several non-real-time
  --> Linux
  --> >> threads.
  --> >>
  --> >> This application seems to have a memory leak because after running
  --> for
  --> >> several hours the OOM-Killer kills this application.
  --> >>
  --> >> I am looking for a memory leak detection tool to help find the
  --> leak.
  --> >>
  --> >>
  --> >>
  --> >> Two years ago in the following mail it was mentioned that making
  --> >> Valgrind aware of Xenomai syscalls was on the todo list.
  --> >>
  --> >> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
  --> >>
  --> >>
  --> >>
  --> >> Has this been done?
  --> >>
  --> >
  --> > No news.
  --> >
  --> >> Does Valgrind work with Xenomai?
  --> >>
  --> >
  --> > Nope.
  --> 
  --> Another way around, at least if you are using the posix skin, is to
  --> compile your application for Linux without Xenomai. If you are using a
  --> legacy API, you can do this with Xenomai/SOLO. If you are using the
  --> native
  --> API, then maybe you can ask gently Philippe to write a native skin for
  --> Xenomai/SOLO.
  --> 
  --> Now, about valgrind, I spent some time thinking about it. A first
  --> modification of valgrind, is to allow dynamic syscall tables, such as
  --> what
  --> Xenomai use. This should be an easy task.
  --> 
  --> The next task is to rewrite all xenomai syscalls in valgrind language
  --> (that is mainly to identify memory reads and writes), this is not a
  --> hard
  --> task, but a rather long one. So, my idea (which remains an idea for
  --> now)
  --> was to write the interface of the syscalls in IDL, and to generate
  --> automatically the code for valgrind.
  --> 
  --> --
  -->                     Gilles.

[Robert McCullough] 

Thanks Gilles for your advice and information.
My application uses the native skin but not to much so it might not take too
much to convert to the posix skin.  I will look into doing this.  As far as
the 5 RTDM drivers go, they will not run under Linux without Xenomai,
correct?  So, I will have to replace them with non-real-time drivers or
simulate them in my application.

I am new to valgrind and have just started to try it.  So, at this time I
would not be very much help in the modification to work with Xenomai.

I am currently using the Linux "top" utility to monitor the memory usage of
my application.  Is this the best utility for this job?

Also, is there a way to monitor the memory usage of my Xenomai tasks and
RTDM drivers?

Best regards, 
Robert McCullough

Re: [Xenomai-help] Does Valgrind work with Xenomai?

[Gilles Chanteperdrix]

Robert McCullough wrote:
>
>
>   --> -----Original Message-----
>   --> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>   --> Sent: Thursday, November 20, 2008 8:25 AM
>   --> To: rpm@xenomai.org
>   --> Cc: rob@domain.hid; xenomai@xenomai.org
>   --> Subject: Re: [Xenomai-help] Does Valgrind work with Xenomai?
>   -->
>   -->
>   --> Philippe Gerum wrote:
>   --> > Robert McCullough wrote:
>   --> >> Hi,
>   --> >>
>   --> >>
>   --> >>
>   --> >> I currently have a C++ application that is using 5 RTDM drivers,
> 2
>   --> >> Xenomai real-time user-space threads and several non-real-time
>   --> Linux
>   --> >> threads.
>   --> >>
>   --> >> This application seems to have a memory leak because after
> running
>   --> for
>   --> >> several hours the OOM-Killer kills this application.
>   --> >>
>   --> >> I am looking for a memory leak detection tool to help find the
>   --> leak.
>   --> >>
>   --> >>
>   --> >>
>   --> >> Two years ago in the following mail it was mentioned that making
>   --> >> Valgrind aware of Xenomai syscalls was on the todo list.
>   --> >>
>   --> >> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
>   --> >>
>   --> >>
>   --> >>
>   --> >> Has this been done?
>   --> >>
>   --> >
>   --> > No news.
>   --> >
>   --> >> Does Valgrind work with Xenomai?
>   --> >>
>   --> >
>   --> > Nope.
>   -->
>   --> Another way around, at least if you are using the posix skin, is to
>   --> compile your application for Linux without Xenomai. If you are using
> a
>   --> legacy API, you can do this with Xenomai/SOLO. If you are using the
>   --> native
>   --> API, then maybe you can ask gently Philippe to write a native skin
> for
>   --> Xenomai/SOLO.
>   -->
>   --> Now, about valgrind, I spent some time thinking about it. A first
>   --> modification of valgrind, is to allow dynamic syscall tables, such
> as
>   --> what
>   --> Xenomai use. This should be an easy task.
>   -->
>   --> The next task is to rewrite all xenomai syscalls in valgrind
> language
>   --> (that is mainly to identify memory reads and writes), this is not a
>   --> hard
>   --> task, but a rather long one. So, my idea (which remains an idea for
>   --> now)
>   --> was to write the interface of the syscalls in IDL, and to generate
>   --> automatically the code for valgrind.
>   -->
>   --> --
>   -->                     Gilles.
>
> [Robert McCullough]
>
> Thanks Gilles for your advice and information.
> My application uses the native skin but not to much so it might not take
> too
> much to convert to the posix skin.  I will look into doing this.  As far
> as
> the 5 RTDM drivers go, they will not run under Linux without Xenomai,
> correct?  So, I will have to replace them with non-real-time drivers or
> simulate them in my application.

There is an experimental branch of RTDM which allows to run RTDM drivers
over plain Linux. I do not remember where it is. Maybe someone can give us
more details?

>
> I am new to valgrind and have just started to try it.  So, at this time I
> would not be very much help in the modification to work with Xenomai.
>
> I am currently using the Linux "top" utility to monitor the memory usage
> of
> my application.  Is this the best utility for this job?
>
> Also, is there a way to monitor the memory usage of my Xenomai tasks and
> RTDM drivers?

No, not yet.

-- 
                    Gilles.