valgrind-users — General discussion list for Valgrind users

RE: [Valgrind-users] Segment overrides

[Vincent Penquerc'h <Vin...@ar...>]

> The current version (1.9.6) supports segment overrides, I think. 
> Certainly the current CVS does.

OK, it's good to hear. I downloaded 1.9.6 today, but I thought I
read on the web page states they're not supported (yet) (in the
section which refers to libGL.so from nVidia, which is said to be
unsupported because of those seg overrides).
Looking again, I now see I had missed the note that says that they
are supported from 1.1.0. Sorry, I should read things twice before
asking :)
Thanks

--
Vincent Penquerc'h 

Re: [Valgrind-users] valgrind - segmentation fault on rh9

[Nicholas N. <nj...@ca...>]

On 27 May 2003, Hong Chen wrote:

> I'm using valgrind to detect leaks in my program without any luck. When
> I  start valgrind :
> valgrind -v myapp args
>
> it worked fine at the very beginning, but when it tried to load a shared
> object , following error messages showed up :
>
> ==2684== Jump to the invalid address stated on the next line
> ==2684==    at 0x0: ???
> ==2684==    Address 0x0 is not stack'd, malloc'd or free'd
> Segmentation fault
>
> Without valgrind, I haven't get any trouble to run myapp. Could anyone
> give me a pointer ? any input would be appreciated.

That's the message you have a variable that is uninitialised, and then you
try to jump to the "address" stored in that variable.  But since your
program works fine normally, I'd guess it's a Valgrind bug.  Can you
provide the full output from running with -v?  Better still, can you trim
down your program into a small example that triggers the error?

Thanks.

N

Re: [Valgrind-users] Segment overrides

[Jeremy F. <je...@go...>]

On Tue, 2003-05-27 at 04:16, Vincent Penquerc'h wrote:

> New to here, and I've hardly used Valgrind yet.
> I was wondering whether segment overrides are due to be implemented,
> and if so, if there is any idea of when ?


The current version (1.9.6) supports segment overrides, I think. 
Certainly the current CVS does.

    J

[Valgrind-users] valgrind - segmentation fault on rh9

[Hong C. <hc...@N-...>]

hi folks,

I'm using valgrind to detect leaks in my program without any luck. When
I  start valgrind :
valgrind -v myapp args

it worked fine at the very beginning, but when it tried to load a shared
object , following error messages showed up : 

==2684== Jump to the invalid address stated on the next line
==2684==    at 0x0: ???
==2684==    Address 0x0 is not stack'd, malloc'd or free'd
Segmentation fault

Without valgrind, I haven't get any trouble to run myapp. Could anyone
give me a pointer ? any input would be appreciated.

thanks
hong

[Valgrind-users] Segment overrides

[Vincent Penquerc'h <Vin...@ar...>]

Hi,

New to here, and I've hardly used Valgrind yet.
I was wondering whether segment overrides are due to be implemented,
and if so, if there is any idea of when ?
Thanks

(sorry for the HTML, it leaves my MUA in text, but my company's
MS Exchange converts it on the way - upgrade scheduled...)

-- 
Vincent Penquerc'h 

Re: [Valgrind-users] Leak detection during program execution

[Nicholas N. <nj...@ca...>]

On 26 May 2003, Stephane Donze wrote:

> HP's Tru64 Unix has a tool that is very similar to valgrind. It's called
> Third Degree (see
> http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40F_HTML/APS30ETE/THRDDGRC.HTM#third-custom-sec ) and has a very nice feature allowing to track memory leaks during program execution. In the .third configuration script you can put a directive triggering the leak detection after a specific function has been called. For instance, if your .third config file contains the following line
>
> new leaks after MyPeriodicFunction every 2
>
> the instrumented program will perform a leak detection every 2 calls to
> MyPeriodicFunction, thus detecting only "real" memory leaks (i.e. the
> memory leaks created by all the code executed between two calls to
> MyPeriodicFunction). See the complete documentation of the .third
> features at
> http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40F_HTML/MAN/MAN5/0125____.HTM
>
> Do you think it feasible to add those features to valgrind ?

Valgrind allows leak checks to be done at arbitrary times by inserting the
VALGRIND_DO_LEAK_CHECK macro into your program.  The disadvantage is that
it does require re-compiling your program.  The advantage is that the
feature is already there :)  Does this suit your needs?

N

[Valgrind-users] Leak detection during program execution

[Stephane D. <ste...@ex...>]

Hello all,

HP's Tru64 Unix has a tool that is very similar to valgrind. It's called
Third Degree (see 
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40F_HTML/APS30ETE/THRDDGRC.HTM#third-custom-sec ) and has a very nice feature allowing to track memory leaks during program execution. In the .third configuration script you can put a directive triggering the leak detection after a specific function has been called. For instance, if your .third config file contains the following line

new leaks after MyPeriodicFunction every 2

the instrumented program will perform a leak detection every 2 calls to
MyPeriodicFunction, thus detecting only "real" memory leaks (i.e. the
memory leaks created by all the code executed between two calls to
MyPeriodicFunction). See the complete documentation of the .third
features at
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V40F_HTML/MAN/MAN5/0125____.HTM

Do you think it feasible to add those features to valgrind ?

Regards,
Stephane Donze

Re: [Valgrind-users] SSL problems

[Nicholas N. <nj...@ca...>]

On Fri, 23 May 2003, Steve G wrote:

> I guess this illustrates the problem:
>
> int main(void)
> {
>         char buf1[20], buf2[20];
>
>
>         memcpy(buf1, buf2, 20);
>
>                           puts(buf1);
>
>
> }
>
> every single byte in buf1 has been written to. Is buf1
> considered uninitialized in the call to puts? Shouldn't the
> memcpy actually be the error? Everything I see output from
> the simplified program above

The V (validity) bits are used to detect if any of the following
operations depend on uninitialised values:

- conditional tests and moves,
- system calls
- memory address computations.

The V bits are not checked simply when a value is read, because partially
defined words are often copied around, due to the common practice of
padding structures to ensure fields are word-aligned.  It doesn't even
complain if you add two uninitialised integers, because that doesn't
affect the behaviour of the program (unless the result is used in one
of the above three operations, then it complains).

N

Re: [Valgrind-users] SSL problems

[Crispin F. <cr...@th...>]

On Fri, 2003-05-23 at 17:57, Steve G wrote:
> >This is a known problem in openssl. It uses uninitialzed 
> >data to generate random numbers.
> 
> Right, but is that a transferable property? I think this is
> something different. The call chain I posted is the
> RC4_key_set call.

Valgrind keeps track of which bytes (bits?) of memory are initialised
and complains when you use them (system call, conditional jump etc). I
suggest you read the stuff about the memcheck skin at:

http://devel-home.kde.org/~sewardj/docs-1.9.5/mc_main.html#errormsgs

which explains when the error messages are printed (hint, you can copy
bogus data around all you want)

As an aside, you can fix the problem by adding a call to 

VALGRIND_MAKE_READABLE( ptr, len )

after the call to RAND_Bytes and your errors will go away.

Crispin

Re: [Valgrind-users] SSL problems

[Steve G <lin...@ya...>]

>This is a known problem in openssl. It uses uninitialzed 
>data to generate random numbers.

Right, but is that a transferable property? I think this is
something different. The call chain I posted is the
RC4_key_set call.

Before I sent the original e-mail, I traced through all the
ssl calls with ddd. The code in ssleay_rand_bytes adds a
number to each byte in the array. Valgrind complains about
this since the bytes are being used unintialized...however,
the buffer has been written to. Every single byte has
changed.

I guess this illustrates the problem:

int main(void)
{
        char buf1[20], buf2[20];
                                                           
                    
        memcpy(buf1, buf2, 20);
                                                           
                          puts(buf1);                      
                 
                                     
}

every single byte in buf1 has been written to. Is buf1
considered uninitialized in the call to puts? Shouldn't the
memcpy actually be the error? Everything I see output from
the simplified program above

-Steve Grubb



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [Valgrind-users] SSL problems

[Crispin F. <cr...@th...>]

On Fri, 2003-05-23 at 15:22, Steve G wrote:
> Hello,
> 
> I've been doing some testing of daemon's using valgrind.
> I've run across a problem with valgrind and have created a
> simple test program. I've tried several different versions
> of valgrind including cvs.
> 
> I've attached a program that can be compiled as:
> 
> gcc -o ssltest ssltest.c -lcrypto

This is a known problem in openssl. It uses uninitialzed data to
generate random numbers. The dodgy code is in md_rand.c (search for
PURIFY). See:

http://www.mail-archive.com/ope...@op.../msg15497.html

(just for reference, your test program can be shortened as follows
(making use of the very useful VALGRIND_* macros)

#include <openssl/rand.h>
#include <openssl/err.h>
#include <valgrind/memcheck.h>

int main(void)
{
   unsigned char rand_buf[20]; 
                                                                    
   if (!RAND_bytes(rand_buf, sizeof(rand_buf)))
      printf("Couldn't obtain random bytes" );

   VALGRIND_CHECK_READABLE( rand_buf, sizeof( rand_buf ) );
   return 0;
}


Crispin

[Valgrind-users] SSL problems

[Steve G <lin...@ya...>]

Hello,

I've been doing some testing of daemon's using valgrind.
I've run across a problem with valgrind and have created a
simple test program. I've tried several different versions
of valgrind including cvs.

I've attached a program that can be compiled as:

gcc -o ssltest ssltest.c -lcrypto

The valgrind line I use is:

valgrind --num-callers=8 --logfile-fd=19 --leak-check=yes
--leak-resolution=high ssltest 19>out

The problem I see is:

==7796== Use of uninitialised value of size 4
==7796==    at 0x40267B6B: RC4_set_key (rc4_skey.c:111)
==7796==    by 0x80485FC: arc4random_stir (in
/home/steve/ssl_test/ssltest)
==7796==    by 0x804862D: main (in
/home/steve/ssl_test/ssltest)
==7796==    by 0x40330A46: __libc_start_main (in
/lib/libc-2.3.2.so)
==7796==    by 0x80484CC: ??? (start.S:81)

If you uncomment the dump_buffer lines & re-run, you can
see that all the bytes are changed/initialized by the call
to RAND_bytes. I see this kind of problem in sshd, stunnel,
or apache when I do testing. Since these are security
related programs, I am curious about what is happening or
correcting the problem.

TIA,
Steve Grubb

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

[Valgrind-users] unhandled opcodes with ioport

[Rupert K. <rk...@mu...>]

Hello everybody,

I just found out that valgrind chokes when trying to access ioports via
inb() or outb(). It complains about unhandled opcodes.

I have attached a short demo code, as well as output from test runs on
my system. I compiled it with gcc 2.95.3 without any options.

Unfortunately, I do know enough about valgrind (and assembler...) to
implement this myself. Probably, some modifications will be necessary to
treat ioports as defined memory even if they have not been written.

Anyone with the necessary skills wants to jump in?

thanks,

Rupert

PS: BIG THANKS to all contributors to this great tool!

[Valgrind-users] Valgrind-crash

[<pa...@pr...>]

Someone might help me?

during use of your program valgrind 1.9.6 on Linux RedHat 8.0 i686-linux-=
=20
with glibc2.3.2-4.80.6 i got the following report, which might be interes=
ting=20
for you. This problem cause, that i cant use for valgrind memory leak=20
detections in my code. Could you please remove this problem, or tell=20
me how to use valgrind to avoid this failure.

best regards

Slavomir

valgrind: vg_scheduler.c:2469 (do_pthread_mutex_lock): Assertion=20
`mutex->__m_owner =3D=3D ((ThreadId)(0))' failed.

sched status:

Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0=
x0
=3D=3D11645=3D=3D    at 0x40170C43: vgAllRoadsLeadToRome_select (vg_inter=
cept.c:95)
=3D=3D11645=3D=3D    by 0x40170D54: __select (vg_intercept.c:681)
=3D=3D11645=3D=3D    by 0x40311A35: ACE_OS::select(int, fd_set*, fd_set*,=
 fd_set*,=20
ACE_Time_Value const*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:4953)
=3D=3D11645=3D=3D    by 0x4036D4C7:=20
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token>=20
>::wait_for_multiple_events(ACE_Select_Reactor_Handle_Set&, ACE_Time_Valu=
e*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/Select_Reactor_T.cpp:106=
5)

Thread 2: status =3D WaitCV, associated_mx =3D 0x430CDD14, associated_cv =
=3D=20
0x4580FC28
=3D=3D11645=3D=3D    at 0x41001CC5: pthread_cond_wait (vg_libpthread.c:10=
82)
=3D=3D11645=3D=3D    by 0x4034F0FE: ACE_OS::cond_timedwait(pthread_cond_t=
*,=20
pthread_mutex_t*, ACE_Time_Value*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:2278)
=3D=3D11645=3D=3D    by 0x4034DF57:=20
ACE_Condition_Thread_Mutex::wait(ACE_Thread_Mutex&, ACE_Time_Value const*=
)=20
(Synch.cpp:649)
=3D=3D11645=3D=3D    by 0x4034DF86: ACE_Condition_Thread_Mutex::wait(ACE_=
Time_Value=20
const*) (Synch.cpp:658)

Thread 3: status =3D Sleeping, associated_mx =3D 0x0, associated_cv =3D 0=
x0
=3D=3D11645=3D=3D    at 0x40170C43: vgAllRoadsLeadToRome_select (vg_inter=
cept.c:95)
=3D=3D11645=3D=3D    by 0x40170D54: __select (vg_intercept.c:681)
=3D=3D11645=3D=3D    by 0x40311A35: ACE_OS::select(int, fd_set*, fd_set*,=
 fd_set*,=20
ACE_Time_Value const*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:4953)
=3D=3D11645=3D=3D    by 0x4036D4C7:=20
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token>=20
>::wait_for_multiple_events(ACE_Select_Reactor_Handle_Set&, ACE_Time_Valu=
e*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/Select_Reactor_T.cpp:106=
5)

Thread 4: status =3D WaitCV, associated_mx =3D 0x4307B238, associated_cv =
=3D=20
0x4307B254
=3D=3D11645=3D=3D    at 0x41001CC5: pthread_cond_wait (vg_libpthread.c:10=
82)
=3D=3D11645=3D=3D    by 0x4034F0FE: ACE_OS::cond_timedwait(pthread_cond_t=
*,=20
pthread_mutex_t*, ACE_Time_Value*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:2278)
=3D=3D11645=3D=3D    by 0x4034DF57:=20
ACE_Condition_Thread_Mutex::wait(ACE_Thread_Mutex&, ACE_Time_Value const*=
)=20
(Synch.cpp:649)
=3D=3D11645=3D=3D    by 0x4034DF86: ACE_Condition_Thread_Mutex::wait(ACE_=
Time_Value=20
const*) (Synch.cpp:658)

Thread 5: status =3D WaitMX, associated_mx =3D 0x4307B0E4, associated_cv =
=3D 0x0
=3D=3D11645=3D=3D    at 0x410019EC: __pthread_mutex_lock (vg_libpthread.c=
:938)
=3D=3D11645=3D=3D    by 0x806460A: PASDispatcher::Service()=20
(/devel/lib/ACE-TAO_debug/ACE_wrappers/ace/OS.i:1382)
=3D=3D11645=3D=3D    by 0x8064337: PASDispatcher::svc() (PASDispatcher.cp=
p:158)
=3D=3D11645=3D=3D    by 0x403D2ADC: ACE_Task_Base::svc_run(void*) (Task.c=
pp:203)

Thread 6: status =3D WaitCV, associated_mx =3D 0x4308562C, associated_cv =
=3D=20
0x43085648
=3D=3D11645=3D=3D    at 0x41001CC5: pthread_cond_wait (vg_libpthread.c:10=
82)
=3D=3D11645=3D=3D    by 0x4034F0FE: ACE_OS::cond_timedwait(pthread_cond_t=
*,=20
pthread_mutex_t*, ACE_Time_Value*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:2278)
=3D=3D11645=3D=3D    by 0x4034DF57:=20
ACE_Condition_Thread_Mutex::wait(ACE_Thread_Mutex&, ACE_Time_Value const*=
)=20
(Synch.cpp:649)
=3D=3D11645=3D=3D    by 0x4034DF86: ACE_Condition_Thread_Mutex::wait(ACE_=
Time_Value=20
const*) (Synch.cpp:658)

Thread 7: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0=
x0
=3D=3D11645=3D=3D    at 0x41001CC5: pthread_cond_wait (vg_libpthread.c:10=
82)
=3D=3D11645=3D=3D    by 0x4034F0FE: ACE_OS::cond_timedwait(pthread_cond_t=
*,=20
pthread_mutex_t*, ACE_Time_Value*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:2278)
=3D=3D11645=3D=3D    by 0x4034DF57:=20
ACE_Condition_Thread_Mutex::wait(ACE_Thread_Mutex&, ACE_Time_Value const*=
)=20
(Synch.cpp:649)
=3D=3D11645=3D=3D    by 0x4034DF86: ACE_Condition_Thread_Mutex::wait(ACE_=
Time_Value=20
const*) (Synch.cpp:658)

Thread 8: status =3D WaitCV, associated_mx =3D 0x4307AA08, associated_cv =
=3D=20
0x4307AA24
=3D=3D11645=3D=3D    at 0x41001CC5: pthread_cond_wait (vg_libpthread.c:10=
82)
=3D=3D11645=3D=3D    by 0x4034F0FE: ACE_OS::cond_timedwait(pthread_cond_t=
*,=20
pthread_mutex_t*, ACE_Time_Value*)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:2278)
=3D=3D11645=3D=3D    by 0x4034DF57:=20
ACE_Condition_Thread_Mutex::wait(ACE_Thread_Mutex&, ACE_Time_Value const*=
)=20
(Synch.cpp:649)
=3D=3D11645=3D=3D    by 0x4034DF86: ACE_Condition_Thread_Mutex::wait(ACE_=
Time_Value=20
const*) (Synch.cpp:658)

Thread 9: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0=
x0
=3D=3D11645=3D=3D    at 0x410019EC: __pthread_mutex_lock (vg_libpthread.c=
:938)
=3D=3D11645=3D=3D    by 0x807D5E1: PASDClienthandler::svc()=20
(/devel/lib/ACE-TAO_debug/ACE_wrappers/ace/OS.i:1382)
=3D=3D11645=3D=3D    by 0x403D2ADC: ACE_Task_Base::svc_run(void*) (Task.c=
pp:203)
=3D=3D11645=3D=3D    by 0x403598A4: ACE_Thread_Adapter::invoke_i()=20
(Thread_Adapter.cpp:150)

Thread 10: status =3D WaitFD, associated_mx =3D 0x0, associated_cv =3D 0x=
0
=3D=3D11645=3D=3D    at 0x411D81B8: __GI___libc_read (in /lib/libc-2.3.2.=
so)
=3D=3D11645=3D=3D    by 0x4030AA63: ACE_OS::read(int, void*, unsigned)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/OS.i:8258)
=3D=3D11645=3D=3D    by 0x40311F7B: ACE::recv_i(int, void*, unsigned)=20
(/devel/libraries/ACE-TAO_debug/ACE_wrappers/ace/ACE.i:226)
=3D=3D11645=3D=3D    by 0x4030EA1B: ACE::recv_n_i(int, void*, unsigned, u=
nsigned*)=20
(ACE.cpp:985)

[Valgrind-users] [PATCH] possibly lost memory using new[] (not STL)

[Crispin F. <val...@fl...>]

Hi,

When using C++ and new[] with a class that has a destructor, it seems as
though the return address from the new[] is 4 bytes into the block
allocated. This causes the region of memory to be marked as 'possibly
lost'. It seems as though the 4 bytes is used to store the number of
items allocated, e.g. in the following program it will contain 1000.

#include <stdlib.h>
#include <stdio.h>

class inner {
public:
   inner() : ptr(0) {}
   ~inner() { if ( ptr ) delete ptr; }
   int * ptr;
};

inner * info;

int main( int argc, char ** argv )
{
   info = new inner[1000];
   exit(0);
}


This can be fixed by allowing pointers 4 bytes into a block created
using new[] and marking them as not lost.

The attached patch works for me [TM] (although I am not sure about the
assumption that the offset is always 4 bytes)

Cheers

Crispin

Re: [Valgrind-users] helgrind segfaulting

[Nicholas N. <nj...@ca...>]

On Wed, 21 May 2003, Yasushi Saito wrote:

> >Also works ok on SuSE 8.2.  You say -lpthread in your command line; if
> >you remove that does it make any difference?
> >
> Helgrind runs fine without -pthread. Here the point of segfault,
> according to gdb:
>
> #0  0x400182b3 in vgSkin_dup_extra_and_update (err=0x40c3a018)
>     at hg_main.c:2288
> 2288       *new_extra = *((HelgrindError*)VG_(get_error_extra)(err));

Ah, that bug.  It's been fixed in the CVS HEAD, you can check it out from
Valgrind's SourceForge page.  (Instructions for building from CVS are in
valgrind/README.)

N

Re: [Valgrind-users] helgrind segfaulting

[Yasushi S. <ys...@hp...>]

Julian Seward wrote:

>On Tuesday 20 May 2003 10:24 pm, Nicholas Nethercote wrote:
>  
>
>>On Tue, 20 May 2003, Yasushi Saito wrote:
>>    
>>
>>>Here's a really simple program:
>>>
>>>#include <netdb.h>
>>>int main()
>>>{
>>>    gethostbyname("www.yahoo.com");
>>>}
>>>
>>>When I compile this program on Redhat 8 (glibc-2.2.93-5, gcc-3.2-7) and
>>>run it under helgrind (1.9.6), it dumps core.
>>>
>>>By the way, this problem doesn't happen with valgrind 1.9.3, but it does
>>>with 1.9.5. Any help is appreciated..
>>>      
>>>
>>I tried it under 1.9.6 and the current HEAD on RH 7.1 and it worked
>>fine... hmm.
>>    
>>
>
>Also works ok on SuSE 8.2.  You say -lpthread in your command line; if
>you remove that does it make any difference?
>
Helgrind runs fine without -pthread. Here the point of segfault, 
according to gdb:

#0  0x400182b3 in vgSkin_dup_extra_and_update (err=0x40c3a018)
    at hg_main.c:2288
2288       *new_extra = *((HelgrindError*)VG_(get_error_extra)(err));

Thanks,
yaz

Re: [Valgrind-users] helgrind segfaulting

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

On Tuesday 20 May 2003 10:24 pm, Nicholas Nethercote wrote:
> On Tue, 20 May 2003, Yasushi Saito wrote:
> > Here's a really simple program:
> >
> > #include <netdb.h>
> > int main()
> > {
> >     gethostbyname("www.yahoo.com");
> > }
> >
> > When I compile this program on Redhat 8 (glibc-2.2.93-5, gcc-3.2-7) and
> > run it under helgrind (1.9.6), it dumps core.
> >
> > By the way, this problem doesn't happen with valgrind 1.9.3, but it does
> > with 1.9.5. Any help is appreciated..
>
> I tried it under 1.9.6 and the current HEAD on RH 7.1 and it worked
> fine... hmm.

Also works ok on SuSE 8.2.  You say -lpthread in your command line; if
you remove that does it make any difference?

J

Re: [Valgrind-users] helgrind segfaulting

[Nicholas N. <nj...@ca...>]

On Tue, 20 May 2003, Yasushi Saito wrote:

> Here's a really simple program:
>
> #include <netdb.h>
> int main()
> {
>     gethostbyname("www.yahoo.com");
> }
>
> When I compile this program on Redhat 8 (glibc-2.2.93-5, gcc-3.2-7) and
> run it under helgrind (1.9.6), it dumps core.
>
> By the way, this problem doesn't happen with valgrind 1.9.3, but it does
> with 1.9.5. Any help is appreciated..

I tried it under 1.9.6 and the current HEAD on RH 7.1 and it worked
fine... hmm.

N

[Valgrind-users] [PATCH] Support SA_SIGINFO and sigcontext in Valgrind 1.9.6

[Bonzini <bo...@gn...>]

This patch allows one to use SA_SIGINFO (both to get info on the signal and to read the
ucontext at the moment the signal was sent), and even if SA_SIGINFO is not used, to
peep at the sigcontext that the Linux kernel puts on the stack right after the signal
number.  In the former case, you can actually modify the ucontext and have the changes
percolate to the executing program, but not without SA_SIGINFO (mostly for ease of
implementation).

The patch turns Valgrind's signal handler into a SA_SIGINFO handler, and stores the
siginfo_t structure for the pending signals into dcss_sigpending which used to be a
boolean.  A signal is considered not to be pending if its si_signo field is zero.

This patch almost allows me to run GNU Smalltalk under Valgrind with generational GC
enabled (which traps SIGSEGV's and needs to look at the fault addresses).  It does
still crash sometimes, but it is a start.

Regards,

Paolo Bonzini

[Valgrind-users] Message about error in pthread_mutex_unlock useless

[<ar...@fl...>]

Hi.

I am the current valgrind maintainer for Debian. A Debian user has request this feature
which could be good to have if is possible. Below is the email.

Best regards.


--- snip ---

hello,

valgrind detects the following error in my code:
==10840== Thread 6:
==10840== pthread_mutex_unlock: mutex is locked by a different thread
==10840==    at 0x40347B3A: __pthread_mutex_unlock (vg_libpthread.c:980)
==10840==    by 0x40347B73: __pthread_mutex_destroy
(vg_libpthread.c:1001)
==10840==    by 0x4020BCA1: __MSG_context_destroy (msg_context.c:110)
==10840==    by 0x4020B95D: __MSG_process_launcher (msg_context.c:63)
==10840==    by 0x40347412: thread_wrapper (vg_libpthread.c:671)
==10840==    by 0x40161280: do__quit (vg_scheduler.c:2154)

That's very well and good, but I cannot debug this case, because I do
not know which other thread does lock this mutex.

I know I should review my code and find it myself, but it would be very
usefull if valgrind could report which other thread it is.

I think about a message like:
==10840== Thread 6:
==10840== pthread_mutex_unlock: mutex is locked by thread 4


I have no idea of how hard it would be, but it would be really great.

Thanks for this wonderful tool, Mt.


--- snip ---

--
Andres Roldan, CSO
Fluidsignal Group

[Valgrind-users] helgrind segfaulting

[Yasushi S. <ys...@hp...>]

Here's a really simple program:

#include <netdb.h>
int main()
{
    gethostbyname("www.yahoo.com");
}

When I compile this program on Redhat 8 (glibc-2.2.93-5, gcc-3.2-7) and run it under helgrind (1.9.6), it dumps core.


% cc -pthread foo.c
% valgrind --skin=helgrind a.out
==3471== Helgrind, a data race detector for x86-linux.
==3471== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.
==3471== Using valgrind-1.9.6, a program instrumentation system for x86-linux.
==3471== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==3471== Estimated CPU clock rate is 1000 MHz
==3471== For more details, rerun with: -v
==3471==
Segmentation fault (core dumped)
% 

By the way, this problem doesn't happen with valgrind 1.9.3, but it does with 1.9.5. Any help is appreciated..

thanks,
yaz

[Valgrind-users] Re: Valgrind & Matlab

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

Matlab assumes malloc etc give 8-byte aligned blocks.  You can
make V do this with --alignment=8.  I should put this in the FAQ
I guess.

J


On Tuesday 20 May 2003 9:30 am, Sami Romdhani wrote:
> Hi,
>
> I have a C++ program which requires the Matlab (www.mathworks.com)
> libraries to work. This is the most usual c++ program, the only thing is
> that it requires matlab libraries in order to read .mat files.
>
> When I use valgrind on a (ripped off) version of my program which was
> not linked with the matlab lib, it works. When linked with the matlab
> libs it does not and the following error message appears when I run
> valgrind on my program:
>
> ==6422== Memcheck, a.k.a. Valgrind, a memory error detector for
> x86-linux.
> ==6422== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
> ==6422== Using valgrind-1.9.6, a program instrumentation system for
> x86-linux.
> ==6422== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
> ==6422== Estimated CPU clock rate is 2787 MHz
> ==6422== For more details, rerun with: -v
> ==6422==
> Table 1. block_array is currupt
> mwmem.c:1010: Assert : Forced Assertion "Unaligned pointer found in
> cache"
> Aborted
>
> I tried to look in the source code of valgrind for this mwmem.c file,
> but couldn't find it. I'm then assuming that this files comes from the
> matlab libraries (difficult to be sure as nm does not work on the matlab
> .so libs)
>
> So, is there any chance to use valgrind with programs linked with matlab
> libraries or not ?
>
> Sami.

Re: [Valgrind-users] Valgrind & Matlab

[Sami R. <sam...@un...>]

It works !
Thanks a lot !

On Tue, 2003-05-20 at 14:00, Nicholas Nethercote wrote:
> On Tue, 20 May 2003, Sami Romdhani wrote:
> 
> > Table 1. block_array is currupt
> > mwmem.c:1010: Assert : Forced Assertion "Unaligned pointer found in
> > cache"
> > Aborted
> >
> > I tried to look in the source code of valgrind for this mwmem.c file,
> > but couldn't find it. I'm then assuming that this files comes from the
> > matlab libraries (difficult to be sure as nm does not work on the matlab
> > .so libs)
> 
> Try running Valgrind with the --alignment=8 option... many implementations
> of malloc() give back 8-byte aligned pointers, Valgrind by default
> (legitimately)  gives back 4-byte aligned pointers, and this breaks some
> programs.
> 
> N
> 
-- 
http://informatik.unibas.ch/personen/romdhani_sami/

Re: [Valgrind-users] Valgrind & Matlab

[Nicholas N. <nj...@ca...>]

On Tue, 20 May 2003, Sami Romdhani wrote:

> Table 1. block_array is currupt
> mwmem.c:1010: Assert : Forced Assertion "Unaligned pointer found in
> cache"
> Aborted
>
> I tried to look in the source code of valgrind for this mwmem.c file,
> but couldn't find it. I'm then assuming that this files comes from the
> matlab libraries (difficult to be sure as nm does not work on the matlab
> .so libs)

Try running Valgrind with the --alignment=8 option... many implementations
of malloc() give back 8-byte aligned pointers, Valgrind by default
(legitimately)  gives back 4-byte aligned pointers, and this breaks some
programs.

N