valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

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

Using SETI (Search Extra Tile-gx Information)
I tried to find some recent news about tile-gx, such as
a newer version of the instruction set, or new processor models
or whatever indicating a sign of active development life.
I find nothing.

To the contrary, what I can find is that
the tile-gx architecture is being replaced by tile-mx,
which is an ARM based chip.
See a.o http://www.mellanox.com/repository/solutions/tile-scm/
and
http://www.bdti.com/InsideDSP/2015/03/03/EZchip
and various other things such as ezchip roadmap.

So, no developer, no user, no company person telling anything,
and public information telling the chip will be replaced.

So, it looks clear that tile-gx  will have to be removed
sooner or later.
IMO, sooner is better: I spent some effort even very recently
on the tile-gx files (as part of a factorisation effort)
and it looks like this (evening/week-end) effort was just spent
for nothing, while some real users have to wait because
their wishes are just put in my TODO list.

The above is some additional info for the discussion we can
have at FOSDEM2017 valgrind BoF.
Maybe we will receive some information from Mellanox before FOSDEM
in the meantime.
But with the current info, it looks doubtful anybody wants to spend
any more effort on maintaining this.


Philippe



On Fri, 2017-01-13 at 21:59 +0100, Julian Seward wrote:
> That's not a fair comparison.  The Solaris port has a very active
> maintainer and (presumably) also has users.  By comparison the Tilegx
> port has shown no signs of life for a considerable period of time,
> despite attempts by more than one person here to contact both maintainers
> and users.  In my view it is valid to discuss whether we should continue
> to have the Tilegx port in the tree.
> 
> J
> 
> On 13/01/17 21:43, Irek Szczesniak wrote:
> > OK, next is to remove the Solaris port of valgrind. OS was
> > discontinued, Oracle does not respond to emails and there is no
> > emulator.
> > 
> > Please remove.
> > 
> > Irek
> > 
> > On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@iv...> wrote:
> >>
> >>
> >> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers
> >> <phi...@sk...>:
> >>>
> >>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
> >>>> On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...>
> >>>> wrote:
> >>>>> On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
> >>>>> <phi...@sk...> wrote:
> >>>>>> No sign of any tilegx user or developer activity since something like
> >>>>>> one year.
> >>>>>> No reply received for question in
> >>>>>> https://sourceforge.net/p/valgrind/mailman/message/35566192/
> >>>>>>
> >>>>>> Is there any tilegx user or developer still active ?
> >>>>>> Should we consider this platform as dead ?
> >>>>>>
> >>>>> I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
> >>>>> and they say they cannot take care of TileGx port in Valgrind for the
> >>>>> time being.
> >>>>
> >>>> Is there any emulator or other way we can use to test changes ? I
> >>>> don't like seeing such a port just disappear...
> >>> Well, if there is
> >>>              no known users,
> >>>          and no (original) developer doing maintenance
> >>>          and no reply from (original) developers to simple questions
> >>>          and no access to a system to test/compile
> >>>          and no nightly build
> >>>          and no tests in SVN
> >>>          and no emulator
> >>>       then IMO, this platform is a candidate to remove.
> >>>         as just keeping this compiling forever for no reason will
> >>>         at the end cost more than just removing it.
> >>
> >>
> >> Agreed here. Although there are regtests under none/tests/tilegx there is no
> >> way
> >> to run them without any access to the machine or emulator.
> >> I.
> >>
> >> ------------------------------------------------------------------------------
> >> Developer Access Program for Intel Xeon Phi Processors
> >> Access to Intel Xeon Phi processor-based developer platforms.
> >> With one year of Intel Parallel Studio XE.
> >> Training and support from Colfax.
> >> Order your platform today. http://sdm.link/xeonphi
> >> _______________________________________________
> >> Valgrind-developers mailing list
> >> Val...@li...
> >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> >>
> > 
> > 
> > 
> 
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Ivo R. <iv...@iv...>]

2017-01-13 22:27 GMT+01:00 Dan Shelton <dan...@gm...>:

> On 13 January 2017 at 21:59, Julian Seward <js...@ac...> wrote:
> >
> > That's not a fair comparison.  The Solaris port has a very active
> > maintainer and (presumably) also has users.
>
> Well, given that Mr Irek was part of the Opensolaris community I THINK
> he was applying sarcasm and a large grain or whole mine of salt to the
> situation.
>
> Also, even that Solaris is now dead, not only per
> http://www.sunhelp.org/ but by the virtue of Oracle having laid off
> more than 150 people of the core os team(!!!!!!), there is still
> Illumos.
>

The information at sunhelp.org is heavily outdated (from 1st December 2016).
Since then, a lot has happened. Have a look at the source cited at
sunhelp.org
and you will find much more fresh information which brings this whole
situation
into reality again.

I.

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

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

That's not a fair comparison.  The Solaris port has a very active
maintainer and (presumably) also has users.  By comparison the Tilegx
port has shown no signs of life for a considerable period of time,
despite attempts by more than one person here to contact both maintainers
and users.  In my view it is valid to discuss whether we should continue
to have the Tilegx port in the tree.

J

On 13/01/17 21:43, Irek Szczesniak wrote:
> OK, next is to remove the Solaris port of valgrind. OS was
> discontinued, Oracle does not respond to emails and there is no
> emulator.
> 
> Please remove.
> 
> Irek
> 
> On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@iv...> wrote:
>>
>>
>> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers
>> <phi...@sk...>:
>>>
>>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
>>>> On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...>
>>>> wrote:
>>>>> On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
>>>>> <phi...@sk...> wrote:
>>>>>> No sign of any tilegx user or developer activity since something like
>>>>>> one year.
>>>>>> No reply received for question in
>>>>>> https://sourceforge.net/p/valgrind/mailman/message/35566192/
>>>>>>
>>>>>> Is there any tilegx user or developer still active ?
>>>>>> Should we consider this platform as dead ?
>>>>>>
>>>>> I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
>>>>> and they say they cannot take care of TileGx port in Valgrind for the
>>>>> time being.
>>>>
>>>> Is there any emulator or other way we can use to test changes ? I
>>>> don't like seeing such a port just disappear...
>>> Well, if there is
>>>              no known users,
>>>          and no (original) developer doing maintenance
>>>          and no reply from (original) developers to simple questions
>>>          and no access to a system to test/compile
>>>          and no nightly build
>>>          and no tests in SVN
>>>          and no emulator
>>>       then IMO, this platform is a candidate to remove.
>>>         as just keeping this compiling forever for no reason will
>>>         at the end cost more than just removing it.
>>
>>
>> Agreed here. Although there are regtests under none/tests/tilegx there is no
>> way
>> to run them without any access to the machine or emulator.
>> I.
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
> 
> 
> 

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Ivo R. <iv...@iv...>]

2017-01-13 21:43 GMT+01:00 Irek Szczesniak <isz...@gm...>:

> OK, next is to remove the Solaris port of valgrind. OS was
> discontinued, Oracle does not respond to emails and there is no
> emulator.


You can say remove OS X port of Valgrind as well in this manner.

Prove your statements.
Who says "[Solaris] OS is discontinued"?
If you are running an x86 machine, an "emulator" is right on your machine -
get x86/Solaris template for VirtualBox [1].

What are your Valgrind contributions in general which give you a position
to say "remove something"?

I.

[1] http://www.oracle.com/technetwork/server-storage/solaris11/downloads/vm-
templates-2245495.html

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Mark W. <mj...@re...>]

On Fri, Jan 13, 2017 at 09:43:07PM +0100, Irek Szczesniak wrote:
> OK, next is to remove the Solaris port of valgrind. OS was
> discontinued, Oracle does not respond to emails and there is no
> emulator.
> 
> Please remove.

You message is inappropriate in this thread. There are no issues with the
valgrind solaris port. It is maintained. Reported bugs get fixed. Ivo is
one of the most active valgrind developers. And he always makes sure other
platforms benefit from his work.

Please take your solaris/oracle rants somewhere else.

Thanks,

Mark

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Irek S. <isz...@gm...>]

OK, next is to remove the Solaris port of valgrind. OS was
discontinued, Oracle does not respond to emails and there is no
emulator.

Please remove.

Irek

On Fri, Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@iv...> wrote:
>
>
> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers
> <phi...@sk...>:
>>
>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
>> > On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...>
>> > wrote:
>> > > On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
>> > > <phi...@sk...> wrote:
>> > >> No sign of any tilegx user or developer activity since something like
>> > >> one year.
>> > >> No reply received for question in
>> > >> https://sourceforge.net/p/valgrind/mailman/message/35566192/
>> > >>
>> > >> Is there any tilegx user or developer still active ?
>> > >> Should we consider this platform as dead ?
>> > >>
>> > > I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
>> > > and they say they cannot take care of TileGx port in Valgrind for the
>> > > time being.
>> >
>> > Is there any emulator or other way we can use to test changes ? I
>> > don't like seeing such a port just disappear...
>> Well, if there is
>>              no known users,
>>          and no (original) developer doing maintenance
>>          and no reply from (original) developers to simple questions
>>          and no access to a system to test/compile
>>          and no nightly build
>>          and no tests in SVN
>>          and no emulator
>>       then IMO, this platform is a candidate to remove.
>>         as just keeping this compiling forever for no reason will
>>         at the end cost more than just removing it.
>
>
> Agreed here. Although there are regtests under none/tests/tilegx there is no
> way
> to run them without any access to the machine or emulator.
> I.
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>



-- 
Irek

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[<pa...@fr...>]

----- Original Message -----
> No sign of any tilegx user or developer activity since something like
> one year.
> No reply received for question in
> https://sourceforge.net/p/valgrind/mailman/message/35566192/
> 
> Is there any tilegx user or developer still active ?
> Should we consider this platform as dead ?
> 
> Philippe


Hi

Perhaps related to this, the parent company of Tilera, EZchip, was acquired by Mellanox about a year ago:

http://www.mellanox.com/page/press_release_item?id=1681

A+
Paul

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

[Ivo R. <iv...@iv...>]

2017-01-12 20:36 GMT+01:00 Philippe Waroquiers <
phi...@sk...>:

> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
> > On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...>
> wrote:
> > > On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
> > > <phi...@sk...> wrote:
> > >> No sign of any tilegx user or developer activity since something like
> > >> one year.
> > >> No reply received for question in
> > >> https://sourceforge.net/p/valgrind/mailman/message/35566192/
> > >>
> > >> Is there any tilegx user or developer still active ?
> > >> Should we consider this platform as dead ?
> > >>
> > > I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
> > > and they say they cannot take care of TileGx port in Valgrind for the
> > > time being.
> >
> > Is there any emulator or other way we can use to test changes ? I
> > don't like seeing such a port just disappear...
> Well, if there is
>              no known users,
>          and no (original) developer doing maintenance
>          and no reply from (original) developers to simple questions
>          and no access to a system to test/compile
>          and no nightly build
>          and no tests in SVN
>          and no emulator
>       then IMO, this platform is a candidate to remove.
>         as just keeping this compiling forever for no reason will
>         at the end cost more than just removing it.
>

Agreed here. Although there are regtests under none/tests/tilegx there is
no way
to run them without any access to the machine or emulator.
I.

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

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

On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
> On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...> wrote:
> > On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
> > <phi...@sk...> wrote:
> >> No sign of any tilegx user or developer activity since something like
> >> one year.
> >> No reply received for question in
> >> https://sourceforge.net/p/valgrind/mailman/message/35566192/
> >>
> >> Is there any tilegx user or developer still active ?
> >> Should we consider this platform as dead ?
> >>
> > I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
> > and they say they cannot take care of TileGx port in Valgrind for the
> > time being.
> 
> Is there any emulator or other way we can use to test changes ? I
> don't like seeing such a port just disappear...
Well, if there is 
             no known users,
         and no (original) developer doing maintenance
         and no reply from (original) developers to simple questions
         and no access to a system to test/compile
         and no nightly build
         and no tests in SVN
         and no emulator
      then IMO, this platform is a candidate to remove.
        as just keeping this compiling forever for no reason will
        at the end cost more than just removing it.

I will at least put this question as one of the things to discuss
in FOSDEM 2017 Valgrind BoF.

Also, IMO, for the future, we also have to put some mandatory
requirements before accepting new platforms such as e.g. provide an
access to a development system, at least for some time ensure a minimum
of effort for maintenance/questions, provide tests, ...

Philippe

Re: [Valgrind-users] [Valgrind-developers] tilegx ?

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

On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mip...@gm...> wrote:
> On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
> <phi...@sk...> wrote:
>> No sign of any tilegx user or developer activity since something like
>> one year.
>> No reply received for question in
>> https://sourceforge.net/p/valgrind/mailman/message/35566192/
>>
>> Is there any tilegx user or developer still active ?
>> Should we consider this platform as dead ?
>>
> I have exchanged a few emails with Tilera/Mellanox compiler enigneers,
> and they say they cannot take care of TileGx port in Valgrind for the
> time being.

Is there any emulator or other way we can use to test changes ? I
don't like seeing such a port just disappear...

----

Bye,
Roland

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

[Valgrind-users] Val-grind with ODBC

[Jaime T. <jai...@gm...>]

Hello everyone,

I am using ODBC in C to communicate with any DB. I connect using

                    client->retcode = SQLDriverConnect(client->dbc,
                                               NULL,
                                               (SQLTCHAR*) dsn,
                                               SQL_NTS,
                                               NULL,
                                               0,
                                               NULL,
                                               SQL_DRIVER_NOPROMPT);
the connection string that I use is:

    char *dsn =
"Driver=MYSQL;Server=x.x.x.x;Port=port;Database=mydb;User=user;Password=pass;"


I can connect properly with Postgres and Mysql, the problem is that i am
running it with Val-grind and it gives me the error below only when i
connect to mysql, when I connect to Postgres I do not get an error:

    ==19927==    by 0x402831: db_connect (db.c:222)
    ==19927==    by 0x4013DF: main (main.c:47)
    ==19927==
    ==19927== LEAK SUMMARY:
    ==19927==    definitely lost: 0 bytes in 0 blocks
    ==19927==    indirectly lost: 0 bytes in 0 blocks
    ==19927==      possibly lost: 176 bytes in 1 blocks
    ==19927==    still reachable: 86,865 bytes in 131 blocks
    ==19927==         suppressed: 0 bytes in 0 blocks
    ==19927==
    ==19927== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
    ==19927== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

The line number that Val-grind says the error is occurring

     db.c:222

is the line where I have the SQLDriverConnet statement. Why does val-grind
says I have possibly lost bytes on the same line when connecting to mysql
but when connecting to Postgres.
Does anyone know what the issue may be here?

NOTE: I have not tried with other DBs, just these 2.

Please help.
Thank you

Re: [Valgrind-users] valgrinding a SSL application

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

> Valgrind is complaining a lot on any SSL function call (some 20.000
> lines) before the first data is exchanged
     [[snip]]

> What is the correct way to deal with this?

The FAQ for Openssl gives the solution.

Re: [Valgrind-users] valgrinding a SSL application

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

On 05/01/17 15:46, Ivo Raisr wrote:

> 2017-01-05 12:54 GMT+01:00 Matthias Apitz <gu...@un...
> <mailto:gu...@un...>>:
>
>     I'm 'valgrinding' a huge client/server application, where the server
>     runs on Linux (SLES 12) and uses SSL (OpenSSL) to communicate with the
>     clients.
>
>     Valgrind is complaining a lot on any SSL function call (some 20.000
>     lines) before the first data is exchanged, i.e. on creating the SSL
>     socket and accepting the connection.
>
>     I know how to suppress such complaints which I can not solve because the
>     full function stack is inside the libssl.so or libcrypto.so
>
>     But, when I read bytes in clear text from the SSL connection the
>     resulting returned 'buf' is invalid too and this goes up the way as
>     invalid into my application layers. See the example below and the
>     resulting valgrind complaints. It does not even help to strncpy(3) the
>     buffer and work with the result. The data in it remains
>     invalid/uninitialized.
>
>     What is the correct way to deal with this?
>
> One of the straightforward ways (workarounds) will be to use a Valgrind
> client request to explicitly set the data buffer as defined.
> See memcheck.h, VALGRIND_MAKE_MEM_DEFINED.

Doing that at the top level is going to be messy though and you probably 
wont get rid of everything.

The underlying problem is likely to be that OpenSSL deliberately mixes 
uninitialised memory into the entropy pool for it's random number 
generator which then pollutes everything derived from that.

It's a fairly well known issue, as anybody that remembers the infamous 
Debian incident where the valgrind warnings were "fixed" by stopping it 
mixing in that uninitialised memory (and in the process destroying the 
randomness) will know...

The ideal solution would be to alter OpenSSL to call 
VALGRIND_MAKE_MEM_DEFINED on that unitialised memory when it adds it to 
the entropy pool so that valgrind thinks it is defined.

Tom

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

Re: [Valgrind-users] valgrinding a SSL application

[Ivo R. <iv...@iv...>]

2017-01-05 12:54 GMT+01:00 Matthias Apitz <gu...@un...>:

>
> Hello,
>
> I'm 'valgrinding' a huge client/server application, where the server
> runs on Linux (SLES 12) and uses SSL (OpenSSL) to communicate with the
> clients.
>
> Valgrind is complaining a lot on any SSL function call (some 20.000
> lines) before the first data is exchanged, i.e. on creating the SSL
> socket and accepting the connection.
>
> I know how to suppress such complaints which I can not solve because the
> full function stack is inside the libssl.so or libcrypto.so
>
> But, when I read bytes in clear text from the SSL connection the
> resulting returned 'buf' is invalid too and this goes up the way as
> invalid into my application layers. See the example below and the
> resulting valgrind complaints. It does not even help to strncpy(3) the
> buffer and work with the result. The data in it remains
> invalid/uninitialized.
>
> What is the correct way to deal with this?
>

One of the straightforward ways (workarounds) will be to use a Valgrind
client request to explicitly set the data buffer as defined.
See memcheck.h, VALGRIND_MAKE_MEM_DEFINED.
I.

Re: [Valgrind-users] Unable to compile on Mac OS X 10.11

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

On Thu, 2017-01-05 at 13:21 +0100, Gabriel Gritsch wrote:
> thank you for the quick answer - it worked.
> 
> I was unable to search the mailing list because the mentioned urls seem to be down:
> http://news.gmane.org/gmane.comp.debugging.valgrind
> http://search.gmane.org
Yes, the gmane shutdown has still some visible effects :(.

I guess that we need to change these URLs to point at the
'born again' gmane but I am not sure to understand the current
state of this new gmane, and which URL to use to point at the search.

Philippe

[Valgrind-users] valgrinding a SSL application

[Matthias A. <gu...@un...>]

Hello,

I'm 'valgrinding' a huge client/server application, where the server
runs on Linux (SLES 12) and uses SSL (OpenSSL) to communicate with the
clients.

Valgrind is complaining a lot on any SSL function call (some 20.000
lines) before the first data is exchanged, i.e. on creating the SSL
socket and accepting the connection.

I know how to suppress such complaints which I can not solve because the
full function stack is inside the libssl.so or libcrypto.so 

But, when I read bytes in clear text from the SSL connection the
resulting returned 'buf' is invalid too and this goes up the way as
invalid into my application layers. See the example below and the
resulting valgrind complaints. It does not even help to strncpy(3) the
buffer and work with the result. The data in it remains
invalid/uninitialized.

What is the correct way to deal with this?

Thanks


example code:

int SLNPOpensslRead(int sock, char *buf, int maxlen)
{
    int r, i;
    int sslError = 0;
    char *env;
    char sslBuf[SLNPBufLen+1];

    ...
    while (1) {
        bzero(sslBuf, maxlen);
        r = BIO_gets(slnpSSL[i].io, sslBuf, maxlen);
        bzero(buf, maxlen);
        if (r >= 0)
            strncpy(buf, sslBuf, r);

        write(2, buf, r);
        ...
   }	

   return r;
}   


valgrind output for the above lines:

==15677== Conditional jump or move depends on uninitialised value(s)
==15677==    at 0x737B702: buffer_gets (in /usr/local/sisis-pap/lib/libcrypto.so.1.0.0)
==15677==    by 0x7377635: BIO_gets (in /usr/local/sisis-pap/lib/libcrypto.so.1.0.0)
==15677==    by 0x574E9B7: SLNPOpensslRead (SLNPOpenssl.c:610)
==15677==    by 0x575273B: SlnpReadBuffer (SLNPSendReceive.c:1248)
==15677==    by 0x5751FE2: SlnpReceive (SLNPSendReceive.c:746)
==15677==    by 0x805A7BD: SlnpMainLoop (OPServer.c:866)
==15677==    by 0x805A11B: OPServer (OPServer.c:256)
==15677==    by 0x8059A84: main (OPDaemon.c:400)
==15677== 
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:buffer_gets
   fun:BIO_gets
   fun:SLNPOpensslRead
   fun:SlnpReadBuffer
   fun:SlnpReceive
   fun:SlnpMainLoop
   fun:OPServer
   fun:main
}
==15677== Conditional jump or move depends on uninitialised value(s)
==15677==    at 0x402C6E7: strncpy (vg_replace_strmem.c:545)
==15677==    by 0x574E9EE: SLNPOpensslRead (SLNPOpenssl.c:613)
==15677==    by 0x575273B: SlnpReadBuffer (SLNPSendReceive.c:1248)
==15677==    by 0x5751FE2: SlnpReceive (SLNPSendReceive.c:746)
==15677==    by 0x805A7BD: SlnpMainLoop (OPServer.c:866)
==15677==    by 0x805A11B: OPServer (OPServer.c:256)
==15677==    by 0x8059A84: main (OPDaemon.c:400)
==15677== 
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:strncpy
   fun:SLNPOpensslRead
   fun:SlnpReadBuffer
   fun:SlnpReceive
   fun:SlnpMainLoop
   fun:OPServer
   fun:main
}
==15677== Conditional jump or move depends on uninitialised value(s)
==15677==    at 0x402C6FD: strncpy (vg_replace_strmem.c:545)
==15677==    by 0x574E9EE: SLNPOpensslRead (SLNPOpenssl.c:613)
==15677==    by 0x575273B: SlnpReadBuffer (SLNPSendReceive.c:1248)
==15677==    by 0x5751FE2: SlnpReceive (SLNPSendReceive.c:746)
==15677==    by 0x805A7BD: SlnpMainLoop (OPServer.c:866)
==15677==    by 0x805A11B: OPServer (OPServer.c:256)
==15677==    by 0x8059A84: main (OPDaemon.c:400)
==15677== 
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:strncpy
   fun:SLNPOpensslRead
   fun:SlnpReadBuffer
   fun:SlnpReceive
   fun:SlnpMainLoop
   fun:OPServer
   fun:main
}
==15677== Syscall param write(buf) points to uninitialised byte(s)
==15677==    at 0x765F2B3: __write_nocancel (in /lib/libc-2.19.so)
==15677==    by 0x574EA08: SLNPOpensslRead (SLNPOpenssl.c:615)
==15677==    by 0x575273B: SlnpReadBuffer (SLNPSendReceive.c:1248)
==15677==    by 0x5751FE2: SlnpReceive (SLNPSendReceive.c:746)
==15677==    by 0x805A7BD: SlnpMainLoop (OPServer.c:866)
==15677==    by 0x805A11B: OPServer (OPServer.c:256)
==15677==    by 0x8059A84: main (OPDaemon.c:400)
==15677==  Address 0xfef41aff is on thread 1's stack
==15677==  in frame #3, created by SlnpReceive (SLNPSendReceive.c:680)
==15677== 
{
   <insert_a_suppression_name_here>
   Memcheck:Param
   write(buf)
   fun:__write_nocancel
   fun:SLNPOpensslRead
   fun:SlnpReadBuffer
   fun:SlnpReceive
   fun:SlnpMainLoop
   fun:OPServer
   fun:main
}
...


-- 
Matthias Apitz, ✉ gu...@un..., ⌂ http://www.unixarea.de/  ☎ +49-176-38902045

Re: [Valgrind-users] Unable to compile on Mac OS X 10.11

[Gabriel G. <ga...@gr...>]

thank you for the quick answer - it worked.

I was unable to search the mailing list because the mentioned urls seem to be down:
http://news.gmane.org/gmane.comp.debugging.valgrind
http://search.gmane.org

thank you and best regards

Gabriel

> Am 05.01.2017 um 11:47 schrieb Philippe Waroquiers <phi...@sk...>:
> 
> On Thu, 2017-01-05 at 10:44 +0100, Gabriel Gritsch wrote:
>> I am unable to compile on Mac OS X 10.11.6
> Problem was already reported on this list the 23 of December,
> a bypass/solution was given by John Reiser.
> Here is a copy:
> 
> 
>> Undefined symbols for architecture x86_64:
>> 
>>  "___bzero", referenced from:
>> 
>>      _hijack_thread_state in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-syswrap-amd64-darwin.o)
>> 
>>      _RRegUniverse__init in libvex-amd64-darwin.a(libvex_amd64_darwin_a-host_generic_regs.o)
> 
> $ grep -r __bzero valgrind-3.12
> 
> ===== coregrind/m_main.c
> #if defined(VGO_darwin) && DARWIN_VERS == DARWIN_10_10
> 
> /* This might also be needed for > DARWIN_10_10, but I have no way
>    to test for that.  Hence '==' rather than '>=' in the version
>    test above. */
> void __bzero ( void* s, UWord n );
> void __bzero ( void* s, UWord n )
> {
>    (void) VG_(memset)( s, 0, n );
> }
> 
> #endif
> =====
> 
> So a timid developer chose "not functional" versus
> "works, but perhaps a few microseconds slower".
> 
> Just change it to
> 	#if defined(VGO_darwin)
> omitting the test of DARWIN_VERS.
> 
> 
> 
> 

Re: [Valgrind-users] Unable to compile on Mac OS X 10.11

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

On Thu, 2017-01-05 at 10:44 +0100, Gabriel Gritsch wrote:
> I am unable to compile on Mac OS X 10.11.6
Problem was already reported on this list the 23 of December,
a bypass/solution was given by John Reiser.
Here is a copy:


> Undefined symbols for architecture x86_64:
>
>   "___bzero", referenced from:
>
>       _hijack_thread_state in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-syswrap-amd64-darwin.o)
>
>       _RRegUniverse__init in libvex-amd64-darwin.a(libvex_amd64_darwin_a-host_generic_regs.o)

$ grep -r __bzero valgrind-3.12

===== coregrind/m_main.c
#if defined(VGO_darwin) && DARWIN_VERS == DARWIN_10_10

/* This might also be needed for > DARWIN_10_10, but I have no way
    to test for that.  Hence '==' rather than '>=' in the version
    test above. */
void __bzero ( void* s, UWord n );
void __bzero ( void* s, UWord n )
{
    (void) VG_(memset)( s, 0, n );
}

#endif
=====

So a timid developer chose "not functional" versus
"works, but perhaps a few microseconds slower".

Just change it to
	#if defined(VGO_darwin)
omitting the test of DARWIN_VERS.

[Valgrind-users] Unable to compile on Mac OS X 10.11

[Gabriel G. <ga...@gr...>]

Hi all,

I am unable to compile on Mac OS X 10.11.6

Xcode command line tools are installed.

Downloaded the valgrind version 3.12.0 from official site:
http://www.valgrind.org/downloads/current.html
http://www.valgrind.org/downloads/valgrind-3.12.0.tar.bz2

./configure (without arguments) runs fine with final output:
         Maximum build arch: amd64
         Primary build arch: amd64
       Secondary build arch: x86
                   Build OS: darwin
       Primary build target: AMD64_DARWIN
     Secondary build target: X86_DARWIN
           Platform variant: vanilla
      Primary -DVGPV string: -DVGPV_amd64_darwin_vanilla=1
         Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin15.supp

but then „make“ files after a while with missing symbol „___bzero“.
Otheres have that problem too but there are no answers:
https://gist.github.com/tapichu/3025307
https://gist.github.com/Jud/3001460

below is the output of last command that fials:

Making all in memcheck
Making all in .
../coregrind/link_tool_exe_darwin 0x138000000 gcc     -o memcheck-amd64-darwin  -arch x86_64 -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign -Wno-tautological-compare -mmacosx-version-min=10.6 -fno-stack-protector -O2 -nodefaultlibs -nostartfiles -Wl,-u,__start -Wl,-e,__start -arch x86_64 memcheck_amd64_darwin-mc_leakcheck.o memcheck_amd64_darwin-mc_malloc_wrappers.o memcheck_amd64_darwin-mc_main.o memcheck_amd64_darwin-mc_translate.o memcheck_amd64_darwin-mc_machine.o memcheck_amd64_darwin-mc_errors.o ../coregrind/libcoregrind-amd64-darwin.a ../VEX/libvex-amd64-darwin.a -lgcc 
link_tool_exe_darwin: /usr/bin/ld -static -arch x86_64 -macosx_version_min 10.6 -o memcheck-amd64-darwin -u __start -e __start -image_base 0x138000000 -stack_addr 0x134000000 -stack_size 0x800000 memcheck_amd64_darwin-mc_leakcheck.o memcheck_amd64_darwin-mc_malloc_wrappers.o memcheck_amd64_darwin-mc_main.o memcheck_amd64_darwin-mc_translate.o memcheck_amd64_darwin-mc_machine.o memcheck_amd64_darwin-mc_errors.o ../coregrind/libcoregrind-amd64-darwin.a ../VEX/libvex-amd64-darwin.a
Undefined symbols for architecture x86_64:
  "___bzero", referenced from:
      _hijack_thread_state in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-syswrap-amd64-darwin.o)
      _RRegUniverse__init in libvex-amd64-darwin.a(libvex_amd64_darwin_a-host_generic_regs.o)
ld: symbol(s) not found for architecture x86_64
make[3]: *** [memcheck-amd64-darwin] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

It would be great if someone could help me.

thank you very much!

Gabriel

Re: [Valgrind-users] Valgrind crash on armv7l

[<Fra...@we...>]

Hi Philippe,

> Also, have you upgraded to 3.12, as suggested by John ?
 
Yes,I updated to 3.12 - could not see any difference to 3.11.

> Also, try with --read-inline-info=no
All the tests I did now (and the backtraces below) are done with this option now -- does not seem to make any difference.

> Do you have the same problem with the none tool ?
You mean "--tool=none"? Looks like it isn't available...
    # valgrind   --tool=none --read-inline-info=no /usr/bin/FanCtrl
    valgrind: failed to start tool 'none' for platform 'arm-linux': No such file or directory

> According to the above, your problem is a SIGSEGV.
> But the trace below is a SIGILL.
> I think that this last signal is used during hw detection.
> You should continue execution till you encounter the 'problematic'
> SIGSEGV.

You are right - I didn't notice that.
If I continue, I hit a SIGSEGV. But this segmentation violation does not happen always at the same code position (I have different backtraces).
One backtrace (I removed the python error lines out of it for better readability):

Program received signal SIGSEGV, Segmentation fault.
resize (table=0x6150cd00) at m_hashtable.c:131
131     m_hashtable.c: No such file or directory.
(gdb) bt
#0  resize (table=0x6150cd00) at m_hashtable.c:131
#1  vgPlain_HT_add_node (table=0x6150cd00, vnode=<optimized out>)
    at m_hashtable.c:152
#2  0x38100d54 in vgPlain_allocEltDedupPA (
    elt=0x38b54a5c <vgPlain_interim_stack+1032856>, eltSzB=36, ddpa=0x61d9a480)
    at m_deduppoolalloc.c:296
#3  vgPlain_allocFixedEltDedupPA (ddpa=0x61d9a480, eltSzB=eltSzB@entry=36,
    elt=elt@entry=0x38b54a5c <vgPlain_interim_stack+1032856>)
    at m_deduppoolalloc.c:319
#4  0x3809eb6c in vgModuleLocal_addDiCfSI (di=di@entry=0x61d9e290,
    base=<optimized out>, len=4,
    cfsi_m=0x38b54a5c <vgPlain_interim_stack+1032856>,
    cfsi_m@entry=0x38b54a44 <vgPlain_interim_stack+1032832>)
    at m_debuginfo/storage.c:839
#5  0x38118368 in run_CF_instructions (
    adi=0x38b54a68 <vgPlain_interim_stack+1032868>,
    restore_ctx=0x38b572f0 <vgPlain_interim_stack+1043244>, fde_arange=0,
    ilen=6772, instrs=..., ctx=0x38b54aac <vgPlain_interim_stack+1032936>,
    record=1 '\001', di=0x61d9e290) at m_debuginfo/readdwarf.c:3616
#6  vgModuleLocal_read_callframe_info_dwarf3 (di=di@entry=0x61d9e290,
    escn_frame=..., frame_avma=frame_avma@entry=0,
    is_ehframe=is_ehframe@entry=0 '\000') at m_debuginfo/readdwarf.c:4182
#7  0x38093580 in vgModuleLocal_read_elf_debug_info (di=di@entry=0x61d9e290)
    at m_debuginfo/readelf.c:3082
#8  0x3808a320 in di_notify_ACHIEVE_ACCEPT_STATE (di=0x61d9e290)
    at m_debuginfo/debuginfo.c:749
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
#9  vgPlain_di_notify_mmap (a=<optimized out>,
    allow_SkFileV=allow_SkFileV@entry=1 '\001', use_fd=use_fd@entry=-1)
    at m_debuginfo/debuginfo.c:1067
#10 0x38054bb4 in valgrind_main (envp=<optimized out>, argv=<optimized out>,
    argc=<optimized out>) at m_main.c:2224
#11 _start_in_C_linux (pArgc=<optimized out>) at m_main.c:3407
#12 0x00000000 in ?? ()


Another run causes a bt that starts with this:
(gdb) bt
#0  vgPlain_HT_gen_lookup (table=<optimized out>,
    node=0x38b54788 <vgPlain_interim_stack+1032132>,
    node@entry=0x38b54780 <vgPlain_interim_stack+1032124>,
    cmp=cmp@entry=0x38100404 <cmp_pool_elt>) at m_hashtable.c:182
#1  0x38100c24 in vgPlain_allocEltDedupPA (
    elt=0x38b54a5c <vgPlain_interim_stack+1032856>, eltSzB=36, ddpa=0x61cdb480)
    at m_deduppoolalloc.c:266
#2  vgPlain_allocFixedEltDedupPA (ddpa=0x61cdb480, eltSzB=eltSzB@entry=36,
    elt=elt@entry=0x38b54a5c <vgPlain_interim_stack+1032856>)
    at m_deduppoolalloc.c:319
#3  0x3809eb6c in vgModuleLocal_addDiCfSI (di=di@entry=0x61cdf290,
    base=<optimized out>, len=4,
    cfsi_m=0x38b54a5c <vgPlain_interim_stack+1032856>,
    cfsi_m@entry=0x38b54a44 <vgPlain_interim_stack+1032832>)
    at m_debuginfo/storage.c:839
#4  0x38118368 in run_CF_instructions (
    adi=0x38b54a68 <vgPlain_interim_stack+1032868>,
    restore_ctx=0x38b572f0 <vgPlain_interim_stack+1043244>, fde_arange=0,
    ilen=40, instrs=..., ctx=0x38b54aac <vgPlain_interim_stack+1032936>,
    record=1 '\001', di=0x61cdf290) at m_debuginfo/readdwarf.c:3616
#5  vgModuleLocal_read_callframe_info_dwarf3 (di=di@entry=0x61cdf290,
    escn_frame=..., frame_avma=frame_avma@entry=0,
    is_ehframe=is_ehframe@entry=0 '\000') at m_debuginfo/readdwarf.c:4182
---Type <return> to continue, or q <return> to quit---
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
#6  0x38093580 in vgModuleLocal_read_elf_debug_info (di=di@entry=0x61cdf290)
    at m_debuginfo/readelf.c:3082
#7  0x3808a320 in di_notify_ACHIEVE_ACCEPT_STATE (di=0x61cdf290)
    at m_debuginfo/debuginfo.c:749

I have also seen a backtrace that ended in some other file, but I failed to save it.


> Note also that during execution, some 'normal' SIGSEGV are raised.
> On amd64, the bt looks like the below (in generated code).
> [...]

This does not seem to happen in my case. I do not see anything that looks similar, and if i press 'c' (continue) after the first SIGSEGV, I get:

    (gdb) c
    Continuing.

    Program terminated with signal SIGSEGV, Segmentation fault.
    The program no longer exists.


Frank

[Valgrind-users] tilegx ?

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

No sign of any tilegx user or developer activity since something like
one year.
No reply received for question in
https://sourceforge.net/p/valgrind/mailman/message/35566192/

Is there any tilegx user or developer still active ?
Should we consider this platform as dead ?

Philippe

Re: [Valgrind-users] Valgrind crash on armv7l

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

On Wed, 2017-01-04 at 13:43 +0100, Fra...@we... wrote:
> Happy new year!
> 
> 
> Am 08.12.2016 14:34 schrieb John Reiser:
> > [...]
> > Most of the time?  Then run valgrind under gdb, get the traceback
> > at the time of the SIGSEGV, and file a bug report against valgrind.
> >     $ gdb valgrind
> >     (gdb) run --tool=memcheck /path/to/the/smallest/program/which/fails
> >     SIGSEGV
> >     (gdb) bt
> >
> >
>  
> It took some weeks until I found time to set things up, but now I have a backtrace with the actual valgrind version (please ignore the python errors, they exist only because of some mis-configuration of gdb build for the target) - see below.
> For me, this looks like there is an issue very early related to detection of the hardware architecture - any idea?
According to the above, your problem is a SIGSEGV.
But the trace below is a SIGILL.
I think that this last signal is used during hw detection.
You should continue execution till you encounter the 'problematic'
SIGSEGV.
Note also that during execution, some 'normal' SIGSEGV are raised.
On amd64, the bt looks like the below (in generated code).

Program received signal SIGSEGV, Segmentation fault.
0x0000000803646dae in ?? ()
(gdb) bt
#0  0x0000000803646dae in ?? ()
#1  0x0000000802ea5f30 in ?? ()
#2  0x0000000802008390 in ?? ()
#3  0x0000000000405eaa in ?? ()
#4  0x0000000802008390 in ?? ()
#5  0x0000000000001c00 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) 

Also, have you upgraded to 3.12, as suggested by John ?


Do you have the same problem with the none tool ?

Also, try with --read-inline-info=no

Philippe

>  
> best regards,
> Frank
>  
>  
>  
> ---------------------------------------------------------------------------
>  
> 
> # gdb valgrind
> Python Exception <type 'exceptions.ImportError'> No module named gdb:
> gdb: warning:
> Could not load the Python gdb module from `/usr/share/gdb/python'.
> Limited Python support is available from the _gdb module.
> Suggest passing --data-directory=/path/to/gdb/data-directory.
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-buildroot-linux-gnueabihf".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from valgrind...(no debugging symbols found)...done.
> (gdb) run --tool=memcheck /usr/bin/FanCtrl
> Starting program: /usr/bin/valgrind --tool=memcheck /usr/bin/FanCtrl
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> process 401 is executing new program: /usr/lib/valgrind/memcheck-arm-linux
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Program received signal SIGILL, Illegal instruction.
> 0x38051308 in vgPlain_machine_get_hwcaps () at m_machine.c:1608
> 1608    m_machine.c: No such file or directory.
> (gdb) bt
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Python Exception <type 'exceptions.ImportError'> No module named gdb.frames:
> #0  0x38051308 in vgPlain_machine_get_hwcaps () at m_machine.c:1608
> #1  0x380527d0 in valgrind_main (envp=0xbeff6ca4, argv=0xbeff6c94, argc=3) at m_main.c:1830
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> #2  _start_in_C_linux (pArgc=0xbeff6c90) at m_main.c:3407
> #3  0x00000000 in ?? ()
> Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>  
>  
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind crash on armv7l

[<Fra...@we...>]

Happy new year!


Am 08.12.2016 14:34 schrieb John Reiser:
> [...]
> Most of the time?  Then run valgrind under gdb, get the traceback
> at the time of the SIGSEGV, and file a bug report against valgrind.
>     $ gdb valgrind
>     (gdb) run --tool=memcheck /path/to/the/smallest/program/which/fails
>     SIGSEGV
>     (gdb) bt
>
>
 
It took some weeks until I found time to set things up, but now I have a backtrace with the actual valgrind version (please ignore the python errors, they exist only because of some mis-configuration of gdb build for the target) - see below.
For me, this looks like there is an issue very early related to detection of the hardware architecture - any idea?
 
best regards,
Frank
 
 
 
---------------------------------------------------------------------------
 

# gdb valgrind
Python Exception <type 'exceptions.ImportError'> No module named gdb:
gdb: warning:
Could not load the Python gdb module from `/usr/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-buildroot-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from valgrind...(no debugging symbols found)...done.
(gdb) run --tool=memcheck /usr/bin/FanCtrl
Starting program: /usr/bin/valgrind --tool=memcheck /usr/bin/FanCtrl
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
process 401 is executing new program: /usr/lib/valgrind/memcheck-arm-linux
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Program received signal SIGILL, Illegal instruction.
0x38051308 in vgPlain_machine_get_hwcaps () at m_machine.c:1608
1608    m_machine.c: No such file or directory.
(gdb) bt
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Python Exception <type 'exceptions.ImportError'> No module named gdb.frames:
#0  0x38051308 in vgPlain_machine_get_hwcaps () at m_machine.c:1608
#1  0x380527d0 in valgrind_main (envp=0xbeff6ca4, argv=0xbeff6c94, argc=3) at m_main.c:1830
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
#2  _start_in_C_linux (pArgc=0xbeff6c90) at m_main.c:3407
#3  0x00000000 in ?? ()
Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 
 

Re: [Valgrind-users] Errors installing Valgrind on Mac OS X 10.11 make[3]: *** [memcheck-amd64-darwin] Error 1

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

> Undefined symbols for architecture x86_64:
>
>   "___bzero", referenced from:
>
>       _hijack_thread_state in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-syswrap-amd64-darwin.o)
>
>       _RRegUniverse__init in libvex-amd64-darwin.a(libvex_amd64_darwin_a-host_generic_regs.o)

$ grep -r __bzero valgrind-3.12

===== coregrind/m_main.c
#if defined(VGO_darwin) && DARWIN_VERS == DARWIN_10_10

/* This might also be needed for > DARWIN_10_10, but I have no way
    to test for that.  Hence '==' rather than '>=' in the version
    test above. */
void __bzero ( void* s, UWord n );
void __bzero ( void* s, UWord n )
{
    (void) VG_(memset)( s, 0, n );
}

#endif
=====

So a timid developer chose "not functional" versus
"works, but perhaps a few microseconds slower".

Just change it to
	#if defined(VGO_darwin)
omitting the test of DARWIN_VERS.

[Valgrind-users] Errors installing Valgrind on Mac OS X 10.11 make[3]: *** [memcheck-amd64-darwin] Error 1

[Alla _ <mod...@gm...>]

Hello!

I am trying to install Valgrind 3.12 for the whole day today (I had a 3.11
version, which worked fine, but on a previous, Mountain Lion, OS).
I have installed:
automake
autoconf

Then, upon downloading and unzipping the Valgrind-3.12 package,
cd this package
./autogen.sh
./configure --prefix=/usr/local
make

Final lines after make command:

Undefined symbols for architecture x86_64:

  "___bzero", referenced from:

      _hijack_thread_state in
libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-syswrap-amd64-darwin.o)

      _RRegUniverse__init in
libvex-amd64-darwin.a(libvex_amd64_darwin_a-host_generic_regs.o)

ld: symbol(s) not found for architecture x86_64

make[3]: *** [memcheck-amd64-darwin] Error 1

make[2]: *** [all-recursive] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2


I will be grateful for your help. I am working on a student's program now,
and I am a newbie in programming.

Thank you!
-- 

*Respectfully,*
*Alla*