Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

VEX error while executing autogen.sh on MAC OS X Yosemite #1

Open
saifthe1 opened this issue Nov 25, 2014 · 2 comments
Open

VEX error while executing autogen.sh on MAC OS X Yosemite #1

saifthe1 opened this issue Nov 25, 2014 · 2 comments

Comments

@saifthe1
Copy link

Hi,

I am trying to build valgrind from source on MAC OS X Yosemite, I followed the instructions on readme file by running autogen however on running automaker -a it generates and error, it complains about ./VEX directory not found. Please could you suggest something.

Thanks,
Saif
@weaversa
Copy link

I am having the same issue. And, svn co svn://svn.valgrind.org/valgrind/trunk gives Connection refused. I haven't found another alternative for getting the latest sources.

@NAThompson
Copy link

Just replicated this issue on Ubuntu and Centos. The guilty commit is

running: aclocal
running: autoheader
running: automake -a
Makefile.am:21: error: required directory ./VEX does not exist
error: while running 'automake -a'
valgrind$ git bisect bad
127950a8d6f5784e382701a20523dccd41d576fd is the first bad commit
commit 127950a8d6f5784e382701a20523dccd41d576fd
Author: sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9>
Date:   Mon Sep 2 12:44:52 2013 +0000

    Rename configure.in to configure.ac to make more recent auto*s happy,
    and also add the automake option "subdir-objects".  As advisde by
    Tromey and Mjw.


    git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13521 a5019735-40e9-0310-863c-91ae7b9d1cf9

:000000 100644 0000000000000000000000000000000000000000 d32d03b63c404e21ef5c48c19b6c641aa2a16df0 A  configure.ac
:100644 000000 9b1c7020315977143b47b31eb3fa0eae90f09a9b 0000000000000000000000000000000000000000 D  configure.in

However, before this, the error message was

coregrind/Makefile.am:442: warning: source file 'm_replacemalloc/vg_replace_malloc.c' is in a subdirectory,
coregrind/Makefile.am:442: but option 'subdir-objects' is disabled
error: while running 'automake -a'

so ostensibly this fixed some problem. . .

Found a workaround by just mkdir VEX, but this only gets me past the ./configure step; the make step fails with

valgrind$ make
make  all-recursive
make[1]: Entering directory `/home/nthompson/valgrind'
Making all in include
make[2]: Entering directory `/home/nthompson/valgrind/include'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/nthompson/valgrind/include'
Making all in VEX
make[2]: Entering directory `/home/nthompson/valgrind/VEX'
make[2]: *** No rule to make target `auxprogs/genoffsets.c', needed by `pub/libvex_guest_offsets.h'.  Stop.
make[2]: Leaving directory `/home/nthompson/valgrind/VEX'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/nthompson/valgrind'
make: *** [all] Error 2

jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue May 20, 2015
Add some cfi directives in the code doing syscall (by Valgrind).
9b0a198 
This allows to attach to Valgrind when VAlgrind is blocked in a syscall
and have GDB producing a stacktrace, rather than being unable
to unwind.
I.e. instead of having:
  (gdb) bt
  #0  0x380460f2 in do_syscall_WRK ()
  (gdb) 
with the directives, we obtain:
   (gdb) bt
   #0  vgPlain_mk_SysRes_x86_linux (val=1) at m_syscall.c:65
   svn2github#1  vgPlain_do_syscall (sysno=168, a1=944907996, a2=1, a3=4294967295, a4=0, a5=0, a6=0, a7=0, a8=0) at m_syscall.c:791
   svn2github#2  0x38031986 in vgPlain_poll (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1) at m_libcfile.c:535
   svn2github#3  0x3807479f in vgPlain_poll_no_eintr (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1)
       at m_gdbserver/remote-utils.c:86
   svn2github#4  0x380752f0 in readchar (single=4096) at m_gdbserver/remote-utils.c:938
   svn2github#5  0x38075ae3 in getpkt (buf=0x61f35020 "") at m_gdbserver/remote-utils.c:997
   svn2github#6  0x38076fcb in server_main () at m_gdbserver/server.c:1048
   svn2github#7  0x38072af2 in call_gdbserver (tid=1, reason=init_reason) at m_gdbserver/m_gdbserver.c:721
   #8  0x380735ba in vgPlain_gdbserver (tid=1) at m_gdbserver/m_gdbserver.c:788
   #9  0x3802c6ef in do_actions_on_error (allow_db_attach=<optimized out>, err=<optimized out>) at m_errormgr.c:532
   #10 pp_Error (err=0x61f580e0, allow_db_attach=1 '\001', xml=1 '\001') at m_errormgr.c:644
   #11 0x3802cc34 in vgPlain_maybe_record_error (tid=1643479264, ekind=8, a=2271560481, s=0x0, extra=0x62937f1c)
       at m_errormgr.c:851
   #12 0x38028821 in vgMemCheck_record_free_error (tid=1, a=2271560481) at mc_errors.c:836
   #13 0x38007b65 in vgMemCheck_free (tid=1, p=0x87654321) at mc_malloc_wrappers.c:496
   #14 0x3807e261 in do_client_request (tid=1) at m_scheduler/scheduler.c:1840
   #15 vgPlain_scheduler (tid=1) at m_scheduler/scheduler.c:1406
   #16 0x3808b6b2 in thread_wrapper (tidW=<optimized out>) at m_syswrap/syswrap-linux.c:102
   #17 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:155
   #18 0x00000000 in ?? ()
   (gdb) 




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15194 a5019735-40e9-0310-863c-91ae7b9d1cf9
jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue May 20, 2015
Patch 5 in a revised series of cleanup patches from Will Schmidt
88877af 
Add a .exp for the pth_cond_destroy_busy for PPC64 big endian.
This is specifically to cover the last line of output as
seen on ppc64BE, which is "ERROR SUMMARY: X errors from 3 contexts",
where X is 6, versus 3 as seen on other architectures.
The additional errors show up on BE during the "Thread svn2github#1: pthread_cond
_destroy: destruction of condition variable being waited upon."

Signed-off-by: Will Schmidt <[email protected]>

This patch fixes Vagrind bugzilla 347686


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15239 a5019735-40e9-0310-863c-91ae7b9d1cf9
cdleonard pushed a commit to cdleonard/valgrind that referenced this issue Nov 26, 2015
Add some cfi directives in the code doing syscall (by Valgrind).
b0a5771 
This allows to attach to Valgrind when VAlgrind is blocked in a syscall
and have GDB producing a stacktrace, rather than being unable
to unwind.
I.e. instead of having:
  (gdb) bt
  #0  0x380460f2 in do_syscall_WRK ()
  (gdb) 
with the directives, we obtain:
   (gdb) bt
   #0  vgPlain_mk_SysRes_x86_linux (val=1) at m_syscall.c:65
   svn2github#1  vgPlain_do_syscall (sysno=168, a1=944907996, a2=1, a3=4294967295, a4=0, a5=0, a6=0, a7=0, a8=0) at m_syscall.c:791
   svn2github#2  0x38031986 in vgPlain_poll (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1) at m_libcfile.c:535
   svn2github#3  0x3807479f in vgPlain_poll_no_eintr (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1)
       at m_gdbserver/remote-utils.c:86
   svn2github#4  0x380752f0 in readchar (single=4096) at m_gdbserver/remote-utils.c:938
   svn2github#5  0x38075ae3 in getpkt (buf=0x61f35020 "") at m_gdbserver/remote-utils.c:997
   svn2github#6  0x38076fcb in server_main () at m_gdbserver/server.c:1048
   svn2github#7  0x38072af2 in call_gdbserver (tid=1, reason=init_reason) at m_gdbserver/m_gdbserver.c:721
   #8  0x380735ba in vgPlain_gdbserver (tid=1) at m_gdbserver/m_gdbserver.c:788
   #9  0x3802c6ef in do_actions_on_error (allow_db_attach=<optimized out>, err=<optimized out>) at m_errormgr.c:532
   #10 pp_Error (err=0x61f580e0, allow_db_attach=1 '\001', xml=1 '\001') at m_errormgr.c:644
   #11 0x3802cc34 in vgPlain_maybe_record_error (tid=1643479264, ekind=8, a=2271560481, s=0x0, extra=0x62937f1c)
       at m_errormgr.c:851
   #12 0x38028821 in vgMemCheck_record_free_error (tid=1, a=2271560481) at mc_errors.c:836
   #13 0x38007b65 in vgMemCheck_free (tid=1, p=0x87654321) at mc_malloc_wrappers.c:496
   #14 0x3807e261 in do_client_request (tid=1) at m_scheduler/scheduler.c:1840
   #15 vgPlain_scheduler (tid=1) at m_scheduler/scheduler.c:1406
   #16 0x3808b6b2 in thread_wrapper (tidW=<optimized out>) at m_syswrap/syswrap-linux.c:102
   #17 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:155
   #18 0x00000000 in ?? ()
   (gdb) 




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15194 a5019735-40e9-0310-863c-91ae7b9d1cf9
cdleonard pushed a commit to cdleonard/valgrind that referenced this issue Nov 26, 2015
Patch 5 in a revised series of cleanup patches from Will Schmidt
a860994 
Add a .exp for the pth_cond_destroy_busy for PPC64 big endian.
This is specifically to cover the last line of output as
seen on ppc64BE, which is "ERROR SUMMARY: X errors from 3 contexts",
where X is 6, versus 3 as seen on other architectures.
The additional errors show up on BE during the "Thread svn2github#1: pthread_cond
_destroy: destruction of condition variable being waited upon."

Signed-off-by: Will Schmidt <[email protected]>

This patch fixes Vagrind bugzilla 347686


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15239 a5019735-40e9-0310-863c-91ae7b9d1cf9
cdleonard pushed a commit to cdleonard/valgrind that referenced this issue Nov 26, 2015
Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits.
bd90e82 
On RHEL7 x86 32 bits, Valgrind unwinder cannot properly unwind
the stack just after a thread creation : the unwinder always retrieves
the same pc/sp/bp.
See below for an example.
This has as consequences that some stack traces are bigger than
needed (i.e. they always fill up the ips array). If
--merge-recursive-frames is given, then the unwinder enters in an
infinite loop (as identical frames will be merged, and the ips array
will never be filled in).
Thi patch adds an additional exit condition : after unwinding
a frame, if the previous sp is >= new sp, then unwinding stops.
Patch has been tested on debian 8/x86, RHEL7/x86.



   0x0417db67 <+55>:    mov    0x18(%esp),%ebx
   0x0417db6b <+59>:    mov    0x28(%esp),%edi
   0x0417db6f <+63>:    mov    $0x78,%eax
   0x0417db74 <+68>:    mov    %ebx,(%ecx)
   0x0417db76 <+70>:    int    $0x80
=> 0x0417db78 <+72>:    pop    %edi
   0x0417db79 <+73>:    pop    %esi
   0x0417db7a <+74>:    pop    %ebx
   0x0417db7b <+75>:    test   %eax,%eax

Valgrind stacktrace gives:
==21261==    at 0x417DB78: clone (clone.S:110)
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
...
(till the array of ips is full)

while gdb stacktrace gives:
(gdb) bt
#0  clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110
svn2github#1  0x00000000 in ?? ()
(gdb) p $pc
$2 = (void (*)()) 0x417db78 <clone+72>
(gdb)


With the fix, valgrind gives:
==21261==    at 0x417DB78: clone (clone.S:110)
==21261==    by 0x424702F: ???
which looks more reasonable.




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15729 a5019735-40e9-0310-863c-91ae7b9d1cf9
jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue Jan 7, 2016
Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits.
f250c4d 
On RHEL7 x86 32 bits, Valgrind unwinder cannot properly unwind
the stack just after a thread creation : the unwinder always retrieves
the same pc/sp/bp.
See below for an example.
This has as consequences that some stack traces are bigger than
needed (i.e. they always fill up the ips array). If
--merge-recursive-frames is given, then the unwinder enters in an
infinite loop (as identical frames will be merged, and the ips array
will never be filled in).
Thi patch adds an additional exit condition : after unwinding
a frame, if the previous sp is >= new sp, then unwinding stops.
Patch has been tested on debian 8/x86, RHEL7/x86.



   0x0417db67 <+55>:    mov    0x18(%esp),%ebx
   0x0417db6b <+59>:    mov    0x28(%esp),%edi
   0x0417db6f <+63>:    mov    $0x78,%eax
   0x0417db74 <+68>:    mov    %ebx,(%ecx)
   0x0417db76 <+70>:    int    $0x80
=> 0x0417db78 <+72>:    pop    %edi
   0x0417db79 <+73>:    pop    %esi
   0x0417db7a <+74>:    pop    %ebx
   0x0417db7b <+75>:    test   %eax,%eax

Valgrind stacktrace gives:
==21261==    at 0x417DB78: clone (clone.S:110)
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
==21261==    by 0x424702F: ???
...
(till the array of ips is full)

while gdb stacktrace gives:
(gdb) bt
#0  clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110
svn2github#1  0x00000000 in ?? ()
(gdb) p $pc
$2 = (void (*)()) 0x417db78 <clone+72>
(gdb)


With the fix, valgrind gives:
==21261==    at 0x417DB78: clone (clone.S:110)
==21261==    by 0x424702F: ???
which looks more reasonable.




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15729 a5019735-40e9-0310-863c-91ae7b9d1cf9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@saifthe1 @NAThompson @weaversa