valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Valgrind on ARM embedded system

[Tom H. <to...@co...>]

On 19/03/14 12:45, Ashoka K wrote:
  on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled.
>
> I tested and found that summary of valgrind output is shown only on
> graceful exit of
> the application. Tested with a small memleak program as described in Valgrind
> documentation.

Memory leaks are only reported when the program finishes, unless you use 
a client request to ask for a check.

Other errors, such as using uninitialised values, are reported as soon 
as they occur.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Valgrind on ARM embedded system

[Ashoka K <ash...@gm...>]

Hi,

I have an ARM based embedded system and running a lrge application which never
returns. I want to use valgrind on this. I cross compiled and built
the valgrind and run
it on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled.

I tested and found that summary of valgrind output is shown only on
graceful exit of
the application. Tested with a small memleak program as described in Valgrind
documentation.

Is there any way to check the the summary of Valgrind found issues while
application is still running, like on returning from any function. Or
is it required to exit
the application so that valgrind summarizes its findings.

The application which i want to run Valgrind on never returns normally.
If graceful exit from process is always a requirement then can we
trust the summary
output of Valgrind if application process is killed with SIGTERM or
any other signal.

-AK

Re: [Valgrind-users] Valgrind with Hadoop/Mahout

[Philippe W. <phi...@sk...>]

On Fri, 2014-03-14 at 04:18 -0700, Mahmood Naderan wrote:
> Hi
> Is it possible to run valgrind (memory leak tool) with this command
> 
> mahout wikipediaXMLSplitter -d enwiki-latest-pages-articles.xml -o
> wikipedia/chunks -c 64
>  
> ?
> It is a java based program.
> Or Valgrind works with C++ codes only?
Valgrind can work with Java applications.
Depending on your platform, you might need to give
the option --smc-check=all-non-file

Note however that to my knowledge, valgrind will not "understand" much
of the Java heap management and/or will not be able to give
"user code stack traces" for the Java JITted code.

So effectively, running valgrind on a Java application can help
for e.g. the JNI code called by Java, but will not be of much use
for the Java code itself.

More knowledgeable people in Java technology might complement
(or correct) the above information.

Philippe
 

Re: [Valgrind-users] Fwd: Support Request

[Tom H. <to...@co...>]

On 18/03/14 17:19, Giuseppe Assalve wrote:
y much for your reply.
>
> Since, as I've written before, I'm new to Linux could you please explain
> to me how I can actually do the two options?
>
> - _you need to provide debug symbols for it_
> If I've well understood I should install the library libc6-dbg on the
> board but where can I find this library for ARM / Angstrom platform?
>
> - _you need to either stop your ld.so getting stripped in such a severe way_
> What do I have to do to stop ld.so?

I can't answer those questions because I simply don't know. I've never 
used that particular linux distribution/development environment.

You need to seek help from people that are expert in that, whether 
that's the people who sold you the environment, or the open source 
community that creates it.

The simple answer to your first question may well be that the platform 
you are using does not provide separate debug packages, but you'd need 
to ask people that know about it to be sure.

The answer to the second is probably that you need to rebuild the 
dynamic linker after modifying the build system to not runs strip on it, 
or to do so less aggressively, but again you need help from somebody who 
knows how that system is built.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Fwd: Support Request

[Giuseppe A. <giu...@sa...>]

Hello,

thank you very much for your reply.

Since, as I've written before, I'm new to Linux could you please explain 
to me how I can actually do the two options?

- _you need to provide debug symbols for it_
If I've well understood I should install the library libc6-dbg on the 
board but where can I find this library for ARM / Angstrom platform?

- _you need to either stop your ld.so getting stripped in such a severe way_
What do I have to do to stop ld.so?

Thank you again for your help
Giuseppe


Il 18/03/2014 17:13, Tom Hughes ha scritto:
> On 18/03/14 15:40, Giuseppe Assalve wrote:
>
>> I'm trying to install Valgrind on an embedded linux platform (Angstrom
>> distribution).
>> I've cross-compiled it Valgrind correctly but when I try to launch it
>> (valgrind ls -al) on the board I have the following error:
>>
>> valgrind:  Fatal error at startup: a function redirection
>> valgrind:  which is mandatory for this platform-tool combination
>> valgrind:  cannot be set up.  Details of the redirection are:
>> valgrind:
>> valgrind:  A must-be-redirected function
>> valgrind:  whose name matches the pattern:      memcpy
>> valgrind:  in an object with soname matching: ld-linux.so.3
>> valgrind:  was not found whilst processing
>> valgrind:  symbols from the object with soname: ld-linux.so.3
>> valgrind:
>> valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
>> valgrind:  package on this machine.  (2, longer term): ask the packagers
>> valgrind:  for your Linux distribution to please in future ship a non-
>> valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
>> valgrind:  that exports the above-named function using the standard
>> valgrind:  calling conventions for this platform.  The package you need
>> valgrind:  to install for fix (1) is called
>> valgrind:
>> valgrind:    On Debian, Ubuntu: libc6-dbg
>> valgrind:    On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
>> valgrind:
>> valgrind:  Cannot continue -- exiting now.  Sorry.
>>
>> Could you please tell me how I can fix this problem?
>
> I believe the answer to your question is in the verbose message which 
> valgrind printed...
>
> To reiterate, you need to either stop your ld.so getting stripped in 
> such a severe way, or you need to provide debug symbols for it.
>
> Tom
>

Re: [Valgrind-users] Fwd: Support Request

[Tom H. <to...@co...>]

On 18/03/14 15:40, Giuseppe Assalve wrote:

> I'm trying to install Valgrind on an embedded linux platform (Angstrom
> distribution).
> I've cross-compiled it Valgrind correctly but when I try to launch it
> (valgrind ls -al) on the board I have the following error:
>
> valgrind:  Fatal error at startup: a function redirection
> valgrind:  which is mandatory for this platform-tool combination
> valgrind:  cannot be set up.  Details of the redirection are:
> valgrind:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      memcpy
> valgrind:  in an object with soname matching: ld-linux.so.3
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux.so.3
> valgrind:
> valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
> valgrind:  package on this machine.  (2, longer term): ask the packagers
> valgrind:  for your Linux distribution to please in future ship a non-
> valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
> valgrind:  that exports the above-named function using the standard
> valgrind:  calling conventions for this platform.  The package you need
> valgrind:  to install for fix (1) is called
> valgrind:
> valgrind:    On Debian, Ubuntu: libc6-dbg
> valgrind:    On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
> valgrind:
> valgrind:  Cannot continue -- exiting now.  Sorry.
>
> Could you please tell me how I can fix this problem?

I believe the answer to your question is in the verbose message which 
valgrind printed...

To reiterate, you need to either stop your ld.so getting stripped in 
such a severe way, or you need to provide debug symbols for it.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Fwd: Support Request

[Giuseppe A. <giu...@sa...>]

Hello,

I'm pretty new to Valgrind (and Linux embedded as well).

I'm trying to install Valgrind on an embedded linux platform (Angstrom
distribution).
I've cross-compiled it Valgrind correctly but when I try to launch it
(valgrind ls -al) on the board I have the following error:

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      memcpy
valgrind:  in an object with soname matching: ld-linux.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux.so.3
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
valgrind:    On Debian, Ubuntu: libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

Could you please tell me how I can fix this problem?
Thank you very much

Re: [Valgrind-users] Cast from float into int

[John R. <jr...@Bi...>]

> When there is a cast from float to integer, what is the VEX instruction
> related to it in instrumented code?

Run "valgrind --help-debug".  Look carefully at the section
"Vex options for all Valgrind tools", particularly
--trace-flags and --trace-notbelow.  Then write a one-line test program
which contains a float-to-integer conversion, run the test program
under valgrind with appropriate flags, and see for yourself.

[Valgrind-users] Cast from float into int

[Domingues L. F. <Lui...@ed...>]

Hello,

When there is a cast from float to integer, what is the VEX instruction
related to it in instrumented code?

Regards,
Luis Domingues

[Valgrind-users] Valgrind with Hadoop/Mahout

[Mahmood N. <nt_...@ya...>]

Hi
Is it possible to run valgrind (memory leak tool) with this command

mahout wikipediaXMLSplitter -d enwiki-latest-pages-articles.xml -o wikipedia/chunks -c 64
 
?
It is a java based program.
Or Valgrind works with C++ codes only?


Regards,
Mahmood

[Valgrind-users] Float cast to int

[Domingues L. F. <lui...@ma...>]

Hello,

For a tool I need to build, I'm using durty calls before some arithmetic
operations. I can catch some basics operations like adds sums, but I
cannot catch a type casting like float into integer.

I'm working on amd64, how can do that?

Regards,
Luis Domingues

Re: [Valgrind-users] Analyzing 32bit applications on X86_64 - no more supported?

[Avi G. <av...@ch...>]

It appears that the x86_64 cross compiler does not support 32bit:
checking for 32 bit build support... no

I'll try to figure this out.
Thanks for your help,
Avi

-----Original Message-----
From: Tom Hughes [mailto:to...@co...] 
Sent: Sunday, March 02, 2014 1:03 PM
To: Avi Gozlan; val...@li...
Subject: Re: Analyzing 32bit applications on X86_64 - no more supported?

On 02/03/14 10:42, Avi Gozlan wrote:

> In the past it was possible to analyze 32bit applications on 64bit OS 
> as mentioned in this post: 
> http://sourceforge.net/p/valgrind/mailman/message/23606386/

Still is.

> I have a similar situation, thus I crossed compiled Valgrind to run it on a X86_64 target. It analyzes 64bit applications very well. However, when trying to analyze 32bit applications I get:
> valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No 
> such file or directory

Then it appears that it probably didn't find the 32 bit toolchain when you built it - check the output of configure to see what it says.

Tom

--
Tom Hughes (to...@co...)
http://compton.nu/

Email secured by Check Point

Re: [Valgrind-users] Analyzing 32bit applications on X86_64 - no more supported?

[Tom H. <to...@co...>]

On 02/03/14 10:42, Avi Gozlan wrote:

> In the past it was possible to analyze 32bit applications on 64bit OS as mentioned in this post: http://sourceforge.net/p/valgrind/mailman/message/23606386/

Still is.

> I have a similar situation, thus I crossed compiled Valgrind to run it on a X86_64 target. It analyzes 64bit applications very well. However, when trying to analyze 32bit applications I get:
> valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory

Then it appears that it probably didn't find the 32 bit toolchain when 
you built it - check the output of configure to see what it says.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Analyzing 32bit applications on X86_64 - no more supported?

[Avi G. <av...@ch...>]

Hi,

In the past it was possible to analyze 32bit applications on 64bit OS as mentioned in this post: http://sourceforge.net/p/valgrind/mailman/message/23606386/

I have a similar situation, thus I crossed compiled Valgrind to run it on a X86_64 target. It analyzes 64bit applications very well. However, when trying to analyze 32bit applications I get:
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory

It appears that memcheck-x86-linux is not generated when cross compiling Valgrind 3.9.0 for X86_64.

I tried to work around this by copying the relevant tools from i386 compilation to /usr/lib. Valgrind run but failed to find most of memory errors.

Is there a way to analyze 32bit applications on X86_64 using Valgrind?

Thanks,
Avi

Re: [Valgrind-users] valgrind on solaris?

[Petr P. <se...@da...>]

On 19. úno 14 19:42, Lionel Cons wrote:
> On 24 May 2012 04:33, Lionel Cons <lio...@go...> wrote:
> > On Thu, Sep 8, 2011 at 10:57 PM, Petr Pavlu <se...@da...> wrote:
> >> Hello,
> >>
> >> I would like to inform the list that I started working on a port
> >> of Valgrind to Solaris OS. The port aims at x86 architecture and
> >> recent Solaris versions (i.e. SunOS 5.11 kernel). Code lives
> >> at [1] but it currently doesn't do much. I'm sending this email
> >> to make sure nobody already works on it.
> >>
> >> [1] https://bitbucket.org/setupji/valgrind-solaris
> >
> > Petr, what's the current status of valgrind on solaris? Is both 32bit
> > and 64bit x86 supported? Are you going to support SPARC64?
> 
> Are there any major updates since May 2012? Are you planning to
> support the (open-)solaris fork "Illumos" [http://www.illumos.org]?

Hello Lionel,

There were many changes since May 2012. We added new syscall
wrappers, support for the door syscall, coredump support,
gdbserver was enabled and many bugs were fixed.

Yes, illumos is supported.

Petr

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Florian K. <fl...@ei...>]

On 02/24/2014 03:26 PM, Roland Mainz wrote:
> On Mon, Feb 24, 2014 at 11:02 AM, Julian Seward <js...@ac...> wrote:
> 
> Just curious:
> Does valgrind have 128bit floating-point support somewhere? If "yes"
> ... could core parts of it be adopted/"dumbed down" to do some of the
> 80bit parts ?

The s390 port supports 128-bit floating point. You could look at that
for how it is integrated. But it won't buy you much otherwise.

The problem with this task is not that it is difficult. The issue is
that it is mostly busy work and the testing part is as unsexy as it is
important.

Maybe somebody with ties into Intel or AMD can convince them to sponsor
a person to do the work....

   Florian

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Roland M. <rol...@nr...>]

On Mon, Feb 24, 2014 at 11:02 AM, Julian Seward <js...@ac...> wrote:
>
>>>> But of course, we all agree it would be nice to have 80 bits floats
>>>> properly supported by Valgrind.
>
> To support this for 64-bit processes would require, roughly:
>
> * add an F80 (80-bit floating point) type to IR
> * add relevant 80-bit equivalents of the relevant IROps
>   (AddF80, SubF80, SinF80, etc)
> * change the front end (guest_amd64_toIR.c) to generate
>   IR that uses those new IROps
> * change the back end (host_amd64_isel.c) to generate 80
>   bit FP instructions from that IR.
>
> Much of the back end stuff could be imported from the x86 (32-bit)
> compilation pipeline.  That already has machinery to generate
> x87 code and in particular to deal with the x87 register-stack
> wierdness.
>
> That would get a baseline simulator (--tool=none) that works OK,
> Getting Memcheck to work requires extra steps:
[snip]

Just curious:
Does valgrind have 128bit floating-point support somewhere? If "yes"
... could core parts of it be adopted/"dumbed down" to do some of the
80bit parts ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) rol...@nr...
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Julian S. <js...@ac...>]

>>> But of course, we all agree it would be nice to have 80 bits floats
>>> properly supported by Valgrind.

To support this for 64-bit processes would require, roughly:

* add an F80 (80-bit floating point) type to IR
* add relevant 80-bit equivalents of the relevant IROps
  (AddF80, SubF80, SinF80, etc)
* change the front end (guest_amd64_toIR.c) to generate
  IR that uses those new IROps
* change the back end (host_amd64_isel.c) to generate 80
  bit FP instructions from that IR.

Much of the back end stuff could be imported from the x86 (32-bit)
compilation pipeline.  That already has machinery to generate
x87 code and in particular to deal with the x87 register-stack
wierdness.

That would get a baseline simulator (--tool=none) that works OK,
Getting Memcheck to work requires extra steps:

* add an I80 (80-bit integer) type to IR
* add 80 bit versions of the few IROps that Memcheck requires
  (CmpwNEZ80, CmpNEZ80, Left80)
* add instruction selection to deal with those.  The tricky bit
  is that these will have to be generated into register-pairs,
  in the style of the existing iselInt128Expr, except that only
  the lowest 16 bits of the high-part register is used.

And comprehensive test cases, of course.  These are the most
important single piece, since they can be used to drive the rest
of the development.

J

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Philippe W. <phi...@sk...>]

On Thu, 2014-02-13 at 12:48 +0100, Lionel Cons wrote:
> >> But of course, we all agree it would be nice to have 80 bits floats
> >> properly supported by Valgrind. It is just nobody has
> time/money/effort
> >> to spend on that :(.
> >
> > Kickstarter project maybe?
> 
> Philippe?
>  
Looks interesting, but I do not think I am qualified to create
(and realise) this project for various reasons
(lack of time, lack of knowledge, and I believe some legal conditions).

But as I understand, Julian is doing some (professional, not amateur
like me) work on Valgrind.
He might be more interested.

Philippe

Re: [Valgrind-users] valgrind on solaris?

[Lionel C. <lio...@gm...>]

On 24 May 2012 04:33, Lionel Cons <lio...@go...> wrote:
> On Thu, Sep 8, 2011 at 10:57 PM, Petr Pavlu <se...@da...> wrote:
>> Hello,
>>
>> I would like to inform the list that I started working on a port
>> of Valgrind to Solaris OS. The port aims at x86 architecture and
>> recent Solaris versions (i.e. SunOS 5.11 kernel). Code lives
>> at [1] but it currently doesn't do much. I'm sending this email
>> to make sure nobody already works on it.
>>
>> [1] https://bitbucket.org/setupji/valgrind-solaris
>
> Petr, what's the current status of valgrind on solaris? Is both 32bit
> and 64bit x86 supported? Are you going to support SPARC64?

Are there any major updates since May 2012? Are you planning to
support the (open-)solaris fork "Illumos" [http://www.illumos.org]?

Lionel

Re: [Valgrind-users] Fatal error at startup with libc6-dbg installed

[Tom H. <to...@co...>]

On 19/02/14 13:47, Robin wrote:

> In Debian Valgrind has a required dependency of libc6-dbg. So I
> removed the deb package and installed from source.
> Same error message without libc6-dbg installed.
>
> It was last working a 2 or 3 months ago, when I getting info for a bug report.
>
> Valgrind version, by the way, is 3.9.0 deb package and source.

Right, so it sounds like you need to be talking to the maintainers of 
valgrind and/or libc in Debian then.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Fatal error at startup with libc6-dbg installed

[Robin <rc....@gm...>]

On 19 February 2014 13:23, Tom Hughes <to...@co...> wrote:
> On 19/02/14 12:56, Robin wrote:
>
>> Paths to dbg:
>> /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so
>> /usr/lib/debug/lib/i386-linux-gnu/ld-2.17.so
>
>
> Note that installing the debug package is only a possible fix - we have no
> way of knowing for sure whether it will work on any particular OS.
>
> What I'm not clear about though is what happens without libc6-dbg - the
> subject of  your mail implies that it only breaks when you have that
> installed? So does it work when you don't have it?
>
>
>> Do I need to create a link ld-linux-x86-64.so.2, somewhere, pointing
>> to the ld-2.17.so?
>
>
> No, that would be a really bad idea.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/


Thanks for the reply

In Debian Valgrind has a required dependency of libc6-dbg. So I
removed the deb package and installed from source.
Same error message without libc6-dbg installed.

It was last working a 2 or 3 months ago, when I getting info for a bug report.

Valgrind version, by the way, is 3.9.0 deb package and source.

Thanks
-- 
rob

Re: [Valgrind-users] Fatal error at startup with libc6-dbg installed

[Tom H. <to...@co...>]

On 19/02/14 12:56, Robin wrote:

> Paths to dbg:
> /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so
> /usr/lib/debug/lib/i386-linux-gnu/ld-2.17.so

Note that installing the debug package is only a possible fix - we have 
no way of knowing for sure whether it will work on any particular OS.

What I'm not clear about though is what happens without libc6-dbg - the 
subject of  your mail implies that it only breaks when you have that 
installed? So does it work when you don't have it?

> Do I need to create a link ld-linux-x86-64.so.2, somewhere, pointing
> to the ld-2.17.so?

No, that would be a really bad idea.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Fatal error at startup with libc6-dbg installed

[Robin <rc....@gm...>]

Linux localhost 3.11-2-amd64 #1 SMP Debian 3.11.10-1 (2013-12-04)
x86_64 GNU/Linux
Debian GNU/Linux unstable (sid) Multiarch

Full error:
valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

Paths to dbg:
/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so
/usr/lib/debug/lib/i386-linux-gnu/ld-2.17.so

Do I need to create a link ld-linux-x86-64.so.2, somewhere, pointing
to the ld-2.17.so?

Thanks

-- 
rob

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[David C. <dc...@gm...>]

Hi Philippe,

The executable not recognised thing is a red-herring I'm sure.

The problem seems to be some kind of process-level lock on locale
resources.

A single instance of valgrind over all our processes runs fine.  The issue
is not the application, it is the parallelisation that I have introduced by
using Python's multiprocess module in order to run batches of valgrind
together.  One valgrind instance takes about a week to run over all our
processes which is why I started to explore the multiprocess route.  For
the moment, I'll scale back and be patient until I understand the locale
issue.

Thank for your help.

Regards,
David.


On Tue, Feb 11, 2014 at 8:32 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Tue, 2014-02-11 at 07:22 +0000, David Carter wrote:
> > Hi Philippe,
> >
> > Thanks for your suggestions, I have got the first part of the
> > information.  It seems there is some contention over locale
> > resources.  Do you agree?
> Well, difficult to say without looking more in depth at the code.
> Taking into account that there are threads still running,
> that the valgrind trace shows that threads are being scheduled,
> I guess the problem is linked to the application, not to valgrind.
>
> It looks to me that the easiest would be to have a way to
> debug the application, trying e.g. a newer gdb and vgdb
> (if the newer gdb supports the strange executable format).
>
> Alternatively, just make a normal executable :).
>
> At this stage, not much can be done from Valgrind side I am afraid.
>
>
> Philippe
>
>
>