|
From: Rich C. <rc...@wi...> - 2012-06-22 04:35:54
|
valgrind revision: 12658 VEX revision: 2400 C compiler: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) Assembler: C library: unknown uname -mrs: Darwin 10.8.0 i386 Vendor version: unknown Nightly build on macbook ( Darwin 10.8.0 i386 ) Started at 2012-06-21 23:05:01 CDT Ended at 2012-06-21 23:35:23 CDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 493 tests, 478 stderr failures, 130 stdout failures, 3 stderrB failures, 3 stdoutB failures, 32 post failures == gdbserver_tests/mchelp (stdoutB) gdbserver_tests/mchelp (stderrB) gdbserver_tests/mcinvokeRU (stdoutB) gdbserver_tests/mcinvokeRU (stderrB) gdbserver_tests/mcinvokeWS (stdoutB) gdbserver_tests/mcinvokeWS (stderrB) gdbserver_tests/nlfork_chain (stdout) gdbserver_tests/nlfork_chain (stderr) memcheck/tests/accounting (stderr) memcheck/tests/addressable (stdout) memcheck/tests/addressable (stderr) memcheck/tests/atomic_incs (stdout) memcheck/tests/atomic_incs (stderr) memcheck/tests/badaddrvalue (stdout) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badfree (stderr) memcheck/tests/badfree3 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badloop (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/badrw (stderr) memcheck/tests/big_blocks_freed_list (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/bug287260 (stderr) memcheck/tests/calloc-overflow (stderr) memcheck/tests/clientperm (stdout) memcheck/tests/clientperm (stderr) memcheck/tests/clireq_nofill (stdout) memcheck/tests/clireq_nofill (stderr) memcheck/tests/custom-overlap (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/darwin/aio (stderr) memcheck/tests/darwin/env (stderr) memcheck/tests/darwin/pth-supp (stderr) memcheck/tests/darwin/scalar (stderr) memcheck/tests/darwin/scalar_fork (stderr) memcheck/tests/darwin/scalar_nocancel (stderr) memcheck/tests/darwin/scalar_vfork (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/deep_templates (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/doublefree (stderr) memcheck/tests/err_disable1 (stderr) memcheck/tests/err_disable2 (stderr) memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/erringfds (stdout) memcheck/tests/erringfds (stderr) memcheck/tests/error_counts (stderr) memcheck/tests/errs1 (stderr) memcheck/tests/execve1 (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/fprw (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/holey_buffer_too_small (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stdout) memcheck/tests/inline (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-possible (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-delta (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long-supps (stderr) memcheck/tests/long_namespace_xml (stdout) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/mallinfo (stderr) memcheck/tests/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (stdout) memcheck/tests/malloc3 (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/malloc_usable (stderr) memcheck/tests/manuel1 (stdout) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel2 (stdout) memcheck/tests/manuel2 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/memalign2 (stderr) memcheck/tests/memalign_test (stderr) memcheck/tests/memcmptest (stdout) memcheck/tests/memcmptest (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mempool2 (stderr) memcheck/tests/metadata (stdout) memcheck/tests/metadata (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/mmaptest (stderr) memcheck/tests/nanoleak2 (stderr) memcheck/tests/nanoleak_supp (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stdout) memcheck/tests/new_override (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/null_socket (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin2-not-quite (stderr) memcheck/tests/origin3-no (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/origin6-fp (stderr) memcheck/tests/overlap (stdout) memcheck/tests/overlap (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stdout) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pdb-realloc (stderr) memcheck/tests/pdb-realloc2 (stdout) memcheck/tests/pdb-realloc2 (stderr) memcheck/tests/pipe (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sbfragment (stdout) memcheck/tests/sbfragment (stderr) memcheck/tests/sh-mem-random (stdout) memcheck/tests/sh-mem-random (stderr) memcheck/tests/sh-mem (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/signal2 (stdout) memcheck/tests/signal2 (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/static_malloc (stderr) memcheck/tests/str_tester (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/test-plo-no (stderr) memcheck/tests/test-plo-yes (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/unit_libcbase (stderr) memcheck/tests/unit_oset (stdout) memcheck/tests/unit_oset (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stdout) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stdout) memcheck/tests/varinfo6 (stderr) memcheck/tests/vcpu_bz2 (stdout) memcheck/tests/vcpu_bz2 (stderr) memcheck/tests/vcpu_fbench (stdout) memcheck/tests/vcpu_fbench (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/vcpu_fnfns (stderr) memcheck/tests/wrap1 (stdout) memcheck/tests/wrap1 (stderr) memcheck/tests/wrap2 (stdout) memcheck/tests/wrap2 (stderr) memcheck/tests/wrap3 (stdout) memcheck/tests/wrap3 (stderr) memcheck/tests/wrap4 (stdout) memcheck/tests/wrap4 (stderr) memcheck/tests/wrap5 (stdout) memcheck/tests/wrap5 (stderr) memcheck/tests/wrap6 (stdout) memcheck/tests/wrap6 (stderr) memcheck/tests/wrap7 (stdout) memcheck/tests/wrap7 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) memcheck/tests/writev1 (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/espindola2 (stderr) memcheck/tests/x86/fpeflags (stderr) memcheck/tests/x86/fprem (stdout) memcheck/tests/x86/fprem (stderr) memcheck/tests/x86/fxsave (stdout) memcheck/tests/x86/fxsave (stderr) memcheck/tests/x86/insn_basic (stdout) memcheck/tests/x86/insn_basic (stderr) memcheck/tests/x86/insn_cmov (stdout) memcheck/tests/x86/insn_cmov (stderr) memcheck/tests/x86/insn_fpu (stdout) memcheck/tests/x86/insn_fpu (stderr) memcheck/tests/x86/insn_mmx (stdout) memcheck/tests/x86/insn_mmx (stderr) memcheck/tests/x86/insn_sse (stdout) memcheck/tests/x86/insn_sse (stderr) memcheck/tests/x86/insn_sse2 (stdout) memcheck/tests/x86/insn_sse2 (stderr) memcheck/tests/x86/more_x86_fp (stdout) memcheck/tests/x86/more_x86_fp (stderr) memcheck/tests/x86/pushfpopf (stdout) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/pushfw_x86 (stdout) memcheck/tests/x86/pushfw_x86 (stderr) memcheck/tests/x86/pushpopmem (stdout) memcheck/tests/x86/pushpopmem (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/x86/sse1_memory (stderr) memcheck/tests/x86/sse2_memory (stdout) memcheck/tests/x86/sse2_memory (stderr) memcheck/tests/x86/tronical (stderr) memcheck/tests/x86/xor-undef-x86 (stdout) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stdout) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stdout) cachegrind/tests/dlclose (stderr) cachegrind/tests/notpower2 (stderr) cachegrind/tests/wrap5 (stdout) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/clreq (stderr) callgrind/tests/notpower2-hwpref (stderr) callgrind/tests/notpower2-use (stderr) callgrind/tests/notpower2-wb (stderr) callgrind/tests/notpower2 (stderr) callgrind/tests/simwork-both (stdout) callgrind/tests/simwork-both (stderr) callgrind/tests/simwork-branch (stdout) callgrind/tests/simwork-branch (stderr) callgrind/tests/simwork-cache (stdout) callgrind/tests/simwork-cache (stderr) callgrind/tests/simwork1 (stdout) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stdout) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stdout) callgrind/tests/simwork3 (stderr) callgrind/tests/threads-use (stderr) callgrind/tests/threads (stderr) massif/tests/alloc-fns-A (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (stderr) massif/tests/alloc-fns-B (post) massif/tests/basic (stderr) massif/tests/basic (post) massif/tests/basic2 (stderr) massif/tests/basic2 (post) massif/tests/big-alloc (stderr) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (stderr) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (stderr) massif/tests/deep-D (post) massif/tests/ignored (stderr) massif/tests/ignored (post) massif/tests/ignoring (stderr) massif/tests/ignoring (post) massif/tests/insig (stderr) massif/tests/insig (post) massif/tests/long-names (stderr) massif/tests/long-names (post) massif/tests/long-time (stderr) massif/tests/long-time (post) massif/tests/malloc_usable (stderr) massif/tests/new-cpp (stderr) massif/tests/new-cpp (post) massif/tests/no-stack-no-heap (stderr) massif/tests/no-stack-no-heap (post) massif/tests/null (stderr) massif/tests/null (post) massif/tests/one (stderr) massif/tests/one (post) massif/tests/overloaded-new (stderr) massif/tests/overloaded-new (post) massif/tests/pages_as_heap (stderr) massif/tests/peak (stderr) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (stderr) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (stderr) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (stderr) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (stderr) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (stderr) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (stderr) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (stderr) massif/tests/zero1 (post) massif/tests/zero2 (stderr) massif/tests/zero2 (post) lackey/tests/true (stderr) none/tests/allexec32 (stdout) none/tests/allexec32 (stderr) none/tests/allexec64 (stdout) none/tests/allexec64 (stderr) none/tests/ansi (stderr) none/tests/args (stdout) none/tests/args (stderr) none/tests/async-sigs (stderr) none/tests/bitfield1 (stderr) none/tests/bug129866 (stdout) none/tests/bug129866 (stderr) none/tests/closeall (stderr) none/tests/cmd-with-special (stderr) none/tests/cmdline5 (stderr) none/tests/coolo_sigaction (stdout) none/tests/coolo_sigaction (stderr) none/tests/coolo_strlen (stderr) none/tests/darwin/access_extended (stderr) none/tests/darwin/apple-main-arg (stderr) none/tests/darwin/rlimit (stderr) none/tests/discard (stdout) none/tests/discard (stderr) none/tests/empty-exe (stderr) none/tests/exec-sigmask (stderr) none/tests/execve (stderr) none/tests/faultstatus (stderr) none/tests/fcntl_setown (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_creat (stderr) none/tests/fdleak_dup (stderr) none/tests/fdleak_dup2 (stderr) none/tests/fdleak_fcntl (stderr) none/tests/fdleak_ipv4 (stdout) none/tests/fdleak_ipv4 (stderr) none/tests/fdleak_open (stderr) none/tests/fdleak_pipe (stderr) none/tests/fdleak_socketpair (stderr) none/tests/floored (stdout) none/tests/floored (stderr) none/tests/fork (stdout) none/tests/fork (stderr) none/tests/fucomip (stderr) none/tests/gxx304 (stderr) none/tests/manythreads (stdout) none/tests/manythreads (stderr) none/tests/map_unaligned (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mmap_fcntl_bug (stderr) none/tests/mq (stderr) none/tests/munmap_exe (stderr) none/tests/nestedfns (stdout) none/tests/nestedfns (stderr) none/tests/nodir (stderr) none/tests/pending (stdout) none/tests/pending (stderr) none/tests/process_vm_readv_writev (stderr) none/tests/procfs-non-linux (stderr) none/tests/pth_atfork1 (stdout) none/tests/pth_atfork1 (stderr) none/tests/pth_blockedsig (stdout) none/tests/pth_blockedsig (stderr) none/tests/pth_cancel1 (stdout) none/tests/pth_cancel1 (stderr) none/tests/pth_cancel2 (stderr) none/tests/pth_cvsimple (stdout) none/tests/pth_cvsimple (stderr) none/tests/pth_empty (stderr) none/tests/pth_exit (stderr) none/tests/pth_exit2 (stderr) none/tests/pth_mutexspeed (stdout) none/tests/pth_mutexspeed (stderr) none/tests/pth_once (stdout) none/tests/pth_once (stderr) none/tests/pth_rwlock (stderr) none/tests/pth_stackalign (stdout) none/tests/pth_stackalign (stderr) none/tests/rcrl (stdout) none/tests/rcrl (stderr) none/tests/readline1 (stdout) none/tests/readline1 (stderr) none/tests/require-text-symbol-1 (stderr) none/tests/require-text-symbol-2 (stderr) none/tests/res_search (stdout) none/tests/res_search (stderr) none/tests/resolv (stdout) none/tests/resolv (stderr) none/tests/rlimit64_nofile (stderr) none/tests/rlimit_nofile (stderr) none/tests/sem (stderr) none/tests/semlimit (stderr) none/tests/sha1_test (stderr) none/tests/shell (stdout) none/tests/shell (stderr) none/tests/shell_nosuchfile (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) none/tests/shortpush (stderr) none/tests/shorts (stderr) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/syscall-restart1 (stderr) none/tests/syscall-restart2 (stderr) none/tests/syslog (stderr) none/tests/system (stderr) none/tests/thread-exits (stdout) none/tests/thread-exits (stderr) none/tests/threaded-fork (stdout) none/tests/threaded-fork (stderr) none/tests/threadederrno (stdout) none/tests/threadederrno (stderr) none/tests/timestamp (stderr) none/tests/vgprintf (stderr) none/tests/x86/aad_aam (stdout) none/tests/x86/aad_aam (stderr) none/tests/x86/badseg (stdout) none/tests/x86/badseg (stderr) none/tests/x86/bt_everything (stdout) none/tests/x86/bt_everything (stderr) none/tests/x86/bt_literal (stdout) none/tests/x86/bt_literal (stderr) none/tests/x86/bug125959-x86 (stdout) none/tests/x86/bug125959-x86 (stderr) none/tests/x86/bug126147-x86 (stdout) none/tests/x86/bug126147-x86 (stderr) none/tests/x86/bug132813-x86 (stdout) none/tests/x86/bug132813-x86 (stderr) none/tests/x86/bug135421-x86 (stdout) none/tests/x86/bug135421-x86 (stderr) none/tests/x86/bug137714-x86 (stdout) none/tests/x86/bug137714-x86 (stderr) none/tests/x86/bug152818-x86 (stdout) none/tests/x86/bug152818-x86 (stderr) none/tests/x86/cmpxchg8b (stdout) none/tests/x86/cmpxchg8b (stderr) none/tests/x86/cpuid (stdout) none/tests/x86/cpuid (stderr) none/tests/x86/cse_fail (stdout) none/tests/x86/fcmovnu (stdout) none/tests/x86/fcmovnu (stderr) none/tests/x86/fpu_lazy_eflags (stdout) none/tests/x86/fpu_lazy_eflags (stderr) none/tests/x86/fxtract (stdout) none/tests/x86/fxtract (stderr) none/tests/x86/getseg (stdout) none/tests/x86/getseg (stderr) none/tests/x86/incdec_alt (stdout) none/tests/x86/incdec_alt (stderr) none/tests/x86/insn_basic (stdout) none/tests/x86/insn_basic (stderr) none/tests/x86/insn_cmov (stdout) none/tests/x86/insn_cmov (stderr) none/tests/x86/insn_fpu (stdout) none/tests/x86/insn_fpu (stderr) none/tests/x86/insn_mmx (stdout) none/tests/x86/insn_mmx (stderr) none/tests/x86/insn_sse (stdout) none/tests/x86/insn_sse (stderr) none/tests/x86/insn_sse2 (stdout) none/tests/x86/insn_sse2 (stderr) none/tests/x86/insn_sse3 (stdout) none/tests/x86/insn_sse3 (stderr) none/tests/x86/jcxz (stdout) none/tests/x86/jcxz (stderr) none/tests/x86/lahf (stdout) none/tests/x86/lahf (stderr) none/tests/x86/looper (stdout) none/tests/x86/looper (stderr) none/tests/x86/movx (stdout) none/tests/x86/movx (stderr) none/tests/x86/pushpopseg (stdout) none/tests/x86/pushpopseg (stderr) none/tests/x86/sbbmisc (stdout) none/tests/x86/sbbmisc (stderr) none/tests/x86/shift_ndep (stdout) none/tests/x86/shift_ndep (stderr) none/tests/x86/smc1 (stdout) none/tests/x86/smc1 (stderr) none/tests/x86/x86locked (stdout) none/tests/x86/x86locked (stderr) none/tests/x86/xadd (stdout) none/tests/x86/xadd (stderr) helgrind/tests/annotate_hbefore (stderr) helgrind/tests/annotate_rwlock (stderr) helgrind/tests/annotate_smart_pointer (stderr) helgrind/tests/cond_timedwait_invalid (stderr) helgrind/tests/free_is_write (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/rwlock_test (stderr) helgrind/tests/t2t_laog (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc04_free_lock (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc10_rec_lock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc13_laog1 (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc15_laog_lockdel (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) drd/tests/annotate_barrier (stderr) drd/tests/annotate_barrier_xml (stderr) drd/tests/annotate_hb_err (stderr) drd/tests/annotate_hb_race (stderr) drd/tests/annotate_hbefore (stderr) drd/tests/annotate_ignore_read (stderr) drd/tests/annotate_ignore_rw (stderr) drd/tests/annotate_ignore_rw2 (stderr) drd/tests/annotate_ignore_write (stderr) drd/tests/annotate_ignore_write2 (stderr) drd/tests/annotate_order_1 (stderr) drd/tests/annotate_order_2 (stderr) drd/tests/annotate_order_3 (stderr) drd/tests/annotate_publish_hg (stderr) drd/tests/annotate_rwlock (stderr) drd/tests/annotate_rwlock_hg (stderr) drd/tests/annotate_smart_pointer (stderr) drd/tests/annotate_smart_pointer2 (stderr) drd/tests/annotate_spinlock (stderr) drd/tests/annotate_static (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/annotate_trace_memory_xml (stderr) drd/tests/atomic_var (stderr) drd/tests/bug-235681 (stderr) drd/tests/circular_buffer (stderr) drd/tests/custom_alloc (stderr) drd/tests/custom_alloc_fiw (stderr) drd/tests/fp_race (stderr) drd/tests/fp_race2 (stderr) drd/tests/fp_race_xml (stderr) drd/tests/free_is_write (stderr) drd/tests/free_is_write2 (stderr) drd/tests/hg01_all_ok (stderr) drd/tests/hg02_deadlock (stderr) drd/tests/hg03_inherit (stderr) drd/tests/hg04_race (stderr) drd/tests/hg05_race2 (stderr) drd/tests/hg06_readshared (stderr) drd/tests/hold_lock_1 (stderr) drd/tests/hold_lock_2 (stderr) drd/tests/linuxthreads_det (stderr) drd/tests/memory_allocation (stderr) drd/tests/monitor_example (stderr) drd/tests/new_delete (stderr) drd/tests/pth_broadcast (stderr) drd/tests/pth_cancel_locked (stderr) drd/tests/pth_cleanup_handler (stderr) drd/tests/pth_cond_race (stderr) drd/tests/pth_cond_race2 (stderr) drd/tests/pth_cond_race3 (stderr) drd/tests/pth_create_chain (stderr) drd/tests/pth_detached (stderr) drd/tests/pth_detached2 (stderr) drd/tests/pth_detached3 (stderr) drd/tests/pth_inconsistent_cond_wait (stderr) drd/tests/pth_mutex_reinit (stderr) drd/tests/pth_once (stderr) drd/tests/pth_process_shared_mutex (stderr) drd/tests/pth_uninitialized_cond (stderr) drd/tests/read_and_free_race (stderr) drd/tests/recursive_mutex (stderr) drd/tests/rwlock_race (stderr) drd/tests/rwlock_test (stderr) drd/tests/rwlock_type_checking (stderr) drd/tests/sem_open (stderr) drd/tests/sem_open2 (stderr) drd/tests/sem_open3 (stderr) drd/tests/sem_open_traced (stderr) drd/tests/sigalrm (stderr) drd/tests/sigaltstack (stderr) drd/tests/tc01_simple_race (stderr) drd/tests/tc02_simple_tls (stderr) drd/tests/tc03_re_excl (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc05_simple_race (stderr) drd/tests/tc06_two_races (stderr) drd/tests/tc07_hbl1 (stdout) drd/tests/tc07_hbl1 (stderr) drd/tests/tc08_hbl2 (stdout) drd/tests/tc08_hbl2 (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc10_rec_lock (stderr) drd/tests/tc11_XCHG (stdout) drd/tests/tc11_XCHG (stderr) drd/tests/tc12_rwl_trivial (stderr) drd/tests/tc13_laog1 (stderr) drd/tests/tc15_laog_lockdel (stderr) drd/tests/tc16_byterace (stderr) drd/tests/tc17_sembar (stderr) drd/tests/tc19_shadowmem (stderr) drd/tests/tc21_pthonce (stdout) drd/tests/tc21_pthonce (stderr) drd/tests/tc23_bogus_condwait (stderr) drd/tests/thread_name (stderr) drd/tests/thread_name_xml (stderr) drd/tests/threaded-fork (stderr) drd/tests/trylock (stderr) drd/tests/unit_bitmap (stderr) drd/tests/unit_vc (stderr) exp-bbv/tests/x86/complex_rep (stderr) exp-bbv/tests/x86/fldcw_check (stderr) exp-bbv/tests/x86/million (stderr) exp-bbv/tests/x86/rep_prefix (stderr) ================================================= ./valgrind-new/cachegrind/tests/chdir.stderr.diff ================================================= --- chdir.stderr.exp 2012-06-21 23:20:32.000000000 -0500 +++ chdir.stderr.out 2012-06-21 23:32:35.000000000 -0500 @@ -1,17 +1,28 @@ -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3800D425: ??? + by 0x3800D5E8: ??? + by 0x380548A7: ??? + by 0x38056737: ??? + by 0x3807BB98: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. + ================================================= ./valgrind-new/cachegrind/tests/clreq.stderr.diff ================================================= --- clreq.stderr.exp 2012-06-21 23:20:32.000000000 -0500 +++ clreq.stderr.out 2012-06-21 23:32:36.000000000 -0500 @@ -0,0 +1,27 @@ + +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3800D425: ??? + by 0x3800D5E8: ??? + by 0x380548A7: ??? + by 0x38056737: ??? + by 0x3807BB98: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. + ================================================= ./valgrind-new/cachegrind/tests/dlclose.stderr.diff ================================================= --- dlclose.stderr.exp 2012-06-21 23:20:32.000000000 -0500 +++ dlclose.stderr.out 2012-06-21 23:32:36.000000000 -0500 @@ -1,17 +1,28 @@ -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3800D425: ??? + by 0x3800D5E8: ??? + by 0x380548A7: ??? + by 0x38056737: ??? + by 0x3807BB98: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. + ================================================= ./valgrind-new/cachegrind/tests/dlclose.stdout.diff ================================================= --- dlclose.stdout.exp 2012-06-21 23:20:32.000000000 -0500 +++ dlclose.stdout.out 2012-06-21 23:32:36.000000000 -0500 @@ -1 +0,0 @@ -This is myprint! ================================================= ./valgrind-new/cachegrind/tests/notpower2.stderr.diff ================================================= --- notpower2.stderr.exp 2012-06-21 23:20:32.000000000 -0500 +++ notpower2.stderr.out 2012-06-21 23:32:36.000000000 -0500 @@ -1,17 +1,28 @@ -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3800D425: ??? + by 0x3800D5E8: ??? + by 0x380548A7: ??? + by 0x38056737: ??? + by 0x3807BB98: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. + ================================================= ./valgrind-new/cachegrind/tests/wrap5.stderr.diff ================================================= --- wrap5.stderr.exp 2012-06-21 23:20:32.000000000 -0500 +++ wrap5.stderr.out 2012-06-21 23:32:36.000000000 -0500 @@ -1,17 +1,28 @@ -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3800D425: ??? + by 0x3800D5E8: ??? + by 0x380548A7: ??? + by 0x38056737: ??? + by 0x3807BB98: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. + ================================================= ./valgrind-new/cachegrind/tests/wrap5.stdout.diff ================================================= --- wrap5.stdout.exp 2012-06-21 23:20:32.000000000 -0500 +++ wrap5.stdout.out 2012-06-21 23:32:36.000000000 -0500 @@ -1,37 +0,0 @@ -computing fact1(7) -in wrapper1-pre: fact(7) -in wrapper2-pre: fact(6) -in wrapper1-pre: fact(5) -in wrapper2-pre: fact(4) -in wrapper1-pre: fact(3) -in wrapper2-pre: fact(2) -in wrapper1-pre: fact(1) -in wrapper2-pre: fact(0) -in wrapper2-post: fact(0) = 1 -in wrapper1-post: fact(1) = 1 -in wrapper2-post: fact(2) = 2 -in wrapper1-post: fact(3) = 6 -in wrapper2-pre: fact(2) -in wrapper1-pre: fact(1) -in wrapper2-pre: fact(0) -in wrapper2-post: fact(0) = 1 -in wrapper1-post: fact(1) = 1 -in wrapper2-post: fact(2) = 2 -in wrapper2-post: fact(4) = 32 -in wrapper1-post: fact(5) = 160 -in wrapper2-pre: fact(2) -in wrapper1-pre: fact(1) -in wrapper2-pre: fact(0) -in wrapper2-post: fact(0) = 1 -in wrapper1-post: fact(1) = 1 -in wrapper2-post: fact(2) = 2 -in wrapper2-post: fact(6) = 972 -in wrapper1-post: fact(7) = 6804 -in wrapper2-pre: fact(2) -in wrapper1-pre: fact(1) -in wrapper2-pre: fact(0) -in wrapper2-post: fact(0) = 1 -in wrapper1-post: fact(1) = 1 -in wrapper2-post: fact(2) = 2 -fact1(7) = 6806 -allocated 51 Lards ================================================= ./valgrind-new/cachegrind/tests/x86/fpu-28-108.stderr.diff ================================================= --- fpu-28-108.stderr.exp 2012-06-21 23:20:32.000000000 -0500 +++ fpu-28-108.stderr.out 2012-06-21 23:32:36.000000000 -0500 @@ -1,17 +1,28 @@ -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3800D425: ??? + by 0x3800D5E8: ??? + by 0x380548A7: ??? + by 0x38056737: ??? + by 0x3807BB98: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. + ================================================= ./valgrind-new/callgrind/tests/clreq.stderr.diff ================================================= --- clreq.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ clreq.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,6 +1,28 @@ -Events : Ir -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: ================================================= ./valgrind-new/callgrind/tests/notpower2-hwpref.stderr.diff ================================================= --- notpower2-hwpref.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ notpower2-hwpref.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/notpower2-use.stderr.diff ================================================= --- notpower2-use.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ notpower2-use.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw AcCost1 SpLoss1 AcCost2 SpLoss2 -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/notpower2-wb.stderr.diff ================================================= --- notpower2-wb.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ notpower2-wb.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw ILdmr DLdmr DLdmw -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/notpower2.stderr.diff ================================================= --- notpower2.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ notpower2.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/simwork-both.stderr.diff ================================================= --- simwork-both.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork-both.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,24 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw Bc Bcm Bi Bim -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: - -Branches: -Mispredicts: -Mispred rate: ================================================= ./valgrind-new/callgrind/tests/simwork-both.stdout.diff ================================================= --- simwork-both.stdout.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork-both.stdout.out 2012-06-21 23:32:37.000000000 -0500 @@ -1 +0,0 @@ -Sum: 1000000 ================================================= ./valgrind-new/callgrind/tests/simwork-branch.stderr.diff ================================================= --- simwork-branch.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork-branch.stderr.out 2012-06-21 23:32:37.000000000 -0500 @@ -1,10 +1,28 @@ -Events : Ir Bc Bcm Bi Bim -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? -I refs: +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -Branches: -Mispredicts: -Mispred rate: ================================================= ./valgrind-new/callgrind/tests/simwork-branch.stdout.diff ================================================= --- simwork-branch.stdout.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork-branch.stdout.out 2012-06-21 23:32:37.000000000 -0500 @@ -1 +0,0 @@ -Sum: 1000000 ================================================= ./valgrind-new/callgrind/tests/simwork-cache.stderr.diff ================================================= --- simwork-cache.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork-cache.stderr.out 2012-06-21 23:32:38.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/simwork-cache.stdout.diff ================================================= --- simwork-cache.stdout.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork-cache.stdout.out 2012-06-21 23:32:37.000000000 -0500 @@ -1 +0,0 @@ -Sum: 1000000 ================================================= ./valgrind-new/callgrind/tests/simwork1.stderr.diff ================================================= --- simwork1.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork1.stderr.out 2012-06-21 23:32:38.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/simwork1.stdout.diff ================================================= --- simwork1.stdout.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork1.stdout.out 2012-06-21 23:32:38.000000000 -0500 @@ -1 +0,0 @@ -Sum: 1000000 ================================================= ./valgrind-new/callgrind/tests/simwork2.stderr.diff ================================================= --- simwork2.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork2.stderr.out 2012-06-21 23:32:38.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw ILdmr DLdmr DLdmw -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/simwork2.stdout.diff ================================================= --- simwork2.stdout.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork2.stdout.out 2012-06-21 23:32:38.000000000 -0500 @@ -1 +0,0 @@ -Sum: 1000000 ================================================= ./valgrind-new/callgrind/tests/simwork3.stderr.diff ================================================= --- simwork3.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork3.stderr.out 2012-06-21 23:32:38.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw AcCost1 SpLoss1 AcCost2 SpLoss2 -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happened in m_mallocfree.c. + +If that doesn't help, please report this bug to: www.valgrind.org + +In the bug report, send all the above text, the valgrind +version, and what OS and version you are using. Thanks. -I refs: -I1 misses: -LLi misses: -I1 miss rate: -LLi miss rate: - -D refs: -D1 misses: -LLd misses: -D1 miss rate: -LLd miss rate: - -LL refs: -LL misses: -LL miss rate: ================================================= ./valgrind-new/callgrind/tests/simwork3.stdout.diff ================================================= --- simwork3.stdout.exp 2012-06-21 23:20:28.000000000 -0500 +++ simwork3.stdout.out 2012-06-21 23:32:38.000000000 -0500 @@ -1 +0,0 @@ -Sum: 1000000 ================================================= ./valgrind-new/callgrind/tests/threads-use.stderr.diff ================================================= --- threads-use.stderr.exp 2012-06-21 23:20:28.000000000 -0500 +++ threads-use.stderr.out 2012-06-21 23:32:38.000000000 -0500 @@ -1,20 +1,28 @@ -Events : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw AcCost1 SpLoss1 AcCost2 SpLoss2 Ge sysCount sysTime -Collected : +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed. + at 0x3801EF25: ??? + by 0x3801F0E8: ??? + by 0x38064A97: ??? + by 0x38066927: ??? + by 0x3808BD88: ??? + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable + at 0x8FE01030: _dyld_start (in /usr/lib/dyld) + + +Note: see also the FAQ in the source distribution. +It contains workarounds to several common problems. +In particular, if Valgrind aborted or crashed after +identifying problems in your program, there's a good chance +that fixing those problems will prevent Valgrind aborting or +crashing, especially if it happe... [truncated message content] |
|
From: Philippe W. <phi...@sk...> - 2012-06-22 21:07:41
|
Regression tests failing on Darwin i386 since quite some time I believe.
Does someone understand the below error ?
pub_core_threadstate.h explicitely tells to align vex on 32 bytes:
...
/* Saved machine context. */
VexGuestArchState vex __attribute__((aligned(32)));
...
The failing assert is:
Addr a_vex = (Addr) & tst->arch.vex;
....
vg_assert(VG_IS_32_ALIGNED(a_vex));
> valgrind revision: 12658
> VEX revision: 2400
> C compiler: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
> Assembler:
> C library: unknown
> uname -mrs: Darwin 10.8.0 i386
> Vendor version: unknown
>
> +valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed.
> + at 0x3800D425: ???
> + by 0x3800D5E8: ???
> + by 0x380548A7: ???
> + by 0x38056737: ???
> + by 0x3807BB98: ???
> +
> +sched status:
> + running_tid=1
> +
> +Thread 1: status = VgTs_Runnable
> + at 0x8FE01030: _dyld_start (in /usr/lib/dyld)
> +
> +
> +Note: see also the FAQ in the source distribution.
> +It contains workarounds to several common problems.
> +In particular, if Valgrind aborted or crashed after
> +identifying problems in your program, there's a good chance
> +that fixing those problems will prevent Valgrind aborting or
> +crashing, especially if it happened in m_mallocfree.c.
> +
> +If that doesn't help, please report this bug to: www.valgrind.org
> +
> +In the bug report, send all the above text, the valgrind
> +version, and what OS and version you are using. Thanks.
|
|
From: Greg P. <gp...@ap...> - 2012-06-22 21:18:56
|
On Jun 22, 2012, at 2:07 PM, Philippe Waroquiers <phi...@sk...> wrote: > Regression tests failing on Darwin i386 since quite some time I believe. > > Does someone understand the below error ? > > pub_core_threadstate.h explicitely tells to align vex on 32 bytes: > ... > /* Saved machine context. */ > VexGuestArchState vex __attribute__((aligned(32))); > ... > > The failing assert is: > Addr a_vex = (Addr) & tst->arch.vex; > .... > vg_assert(VG_IS_32_ALIGNED(a_vex)); Not sufficient. attribute(aligned) won't work unless all of the containing structs are also aligned. You need the ThreadState and ThreadArchState to be aligned as well. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: John R. <jr...@bi...> - 2012-06-22 21:40:57
|
>> pub_core_threadstate.h explicitely tells to align vex on 32 bytes: >> ... >> /* Saved machine context. */ >> VexGuestArchState vex __attribute__((aligned(32))); >> ... >> >> The failing assert is: >> Addr a_vex = (Addr) & tst->arch.vex; >> .... >> vg_assert(VG_IS_32_ALIGNED(a_vex)); > > Not sufficient. attribute(aligned) won't work unless all of the containing structs are also aligned. You need the ThreadState and ThreadArchState to be aligned as well. That's a compiler bug. The compiler must automatically propagate alignment requirements: first by maximum within a union, then outward to each enclosing union or struct. -- |
|
From: Philippe W. <phi...@sk...> - 2012-06-22 22:10:04
|
On Fri, 2012-06-22 at 14:41 -0700, John Reiser wrote:
> >> pub_core_threadstate.h explicitely tells to align vex on 32 bytes:
> >> ...
> >> /* Saved machine context. */
> >> VexGuestArchState vex __attribute__((aligned(32)));
> >> ...
> >>
> >> The failing assert is:
> >> Addr a_vex = (Addr) & tst->arch.vex;
> >> ....
> >> vg_assert(VG_IS_32_ALIGNED(a_vex));
> >
> > Not sufficient. attribute(aligned) won't work unless all of the containing structs are also aligned. You need the ThreadState and ThreadArchState to be aligned as well.
>
> That's a compiler bug. The compiler must automatically propagate
> alignment requirements: first by maximum within a union, then
> outward to each enclosing union or struct.
Effectively, the compiler is supposed to align the field.
Here is an extract of the gcc doc:
As in the preceding examples, you can explicitly specify the
alignment (in bytes) that you wish the compiler to use for a given
variable or structure field.
A little bit after, however, one find the below.
Is the MacOs linker not supporting 32 bytes alignment ?
Note that the effectiveness of `aligned' attributes may be limited
by inherent limitations in your linker. On many systems, the
linker is only able to arrange for variables to be aligned up to a
certain maximum alignment. (For some linkers, the maximum
supported alignment may be very very small.) If your linker is
only able to align variables up to a maximum of 8 byte alignment,
then specifying `aligned(16)' in an `__attribute__' will still
only provide you with 8 byte alignment. See your linker
documentation for further information.
|
|
From: Julian S. <js...@ac...> - 2012-06-23 07:19:22
|
This seems like is related to r12648. Not sure what the background to that change is though. I will spark up my mac box and have a look. I thought I had all this alignment stuff figured out already. J On Saturday, June 23, 2012, Philippe Waroquiers wrote: > On Fri, 2012-06-22 at 14:41 -0700, John Reiser wrote: > > >> pub_core_threadstate.h explicitely tells to align vex on 32 bytes: > > >> ... > > >> /* Saved machine context. */ > > >> VexGuestArchState vex __attribute__((aligned(32))); > > >> ... > > >> > > >> The failing assert is: > > >> Addr a_vex = (Addr) & tst->arch.vex; > > >> .... > > >> vg_assert(VG_IS_32_ALIGNED(a_vex)); > > > > > > Not sufficient. attribute(aligned) won't work unless all of the > > > containing structs are also aligned. You need the ThreadState and > > > ThreadArchState to be aligned as well. > > > > That's a compiler bug. The compiler must automatically propagate > > alignment requirements: first by maximum within a union, then > > outward to each enclosing union or struct. > > Effectively, the compiler is supposed to align the field. > Here is an extract of the gcc doc: > > As in the preceding examples, you can explicitly specify the > alignment (in bytes) that you wish the compiler to use for a given > variable or structure field. > > A little bit after, however, one find the below. > Is the MacOs linker not supporting 32 bytes alignment ? > > Note that the effectiveness of `aligned' attributes may be limited > by inherent limitations in your linker. On many systems, the > linker is only able to arrange for variables to be aligned up to a > certain maximum alignment. (For some linkers, the maximum > supported alignment may be very very small.) If your linker is > only able to align variables up to a maximum of 8 byte alignment, > then specifying `aligned(16)' in an `__attribute__' will still > only provide you with 8 byte alignment. See your linker > documentation for further information. > > > > --------------------------------------------------------------------------- > --- Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Philippe W. <phi...@sk...> - 2012-06-23 13:28:22
|
On Sat, 2012-06-23 at 09:17 +0200, Julian Seward wrote: > This seems like is related to r12648. Not sure what the background > to that change is though. I will spark up my mac box and have a look. > I thought I had all this alignment stuff figured out already. The same assert was already failing before (e.g. the tests of r12595, 30 may). It looks like r12648 is a trial by Bart to fix this assert, but it did not persuade the compiler and/or the linker to do the required alignment. The assert align 32 was added in r12569 (AVX support). Before, the alignment requirement was 16: svn diff -r12568:12569 ... - vg_assert(VG_IS_16_ALIGNED(a_vex)); - vg_assert(VG_IS_16_ALIGNED(a_vexsh1)); - vg_assert(VG_IS_16_ALIGNED(a_vexsh2)); - vg_assert(VG_IS_16_ALIGNED(a_spill)); + vg_assert(VG_IS_32_ALIGNED(a_vex)); + vg_assert(VG_IS_32_ALIGNED(a_vexsh1)); + vg_assert(VG_IS_32_ALIGNED(a_vexsh2)); + vg_assert(VG_IS_32_ALIGNED(a_spill)); ... Philippe |
|
From: Julian S. <js...@ac...> - 2012-06-25 09:08:21
|
On Saturday, June 23, 2012, Philippe Waroquiers wrote: > On Sat, 2012-06-23 at 09:17 +0200, Julian Seward wrote: > > This seems like is related to r12648. Not sure what the background > > to that change is though. I will spark up my mac box and have a look. > > I thought I had all this alignment stuff figured out already. > > The same assert was already failing before (e.g. > the tests of r12595, 30 may). > > It looks like r12648 is a trial by Bart to fix this assert, but it > did not persuade the compiler and/or the linker to do the required > alignment. I tried to reproduced the failure, both with and without the r12648 change, but failed. This is on Macos 10.7.3 (Lion, recently updated) with the default XCode, on a non-AVX-capable CPU. So I am not sure what is going on -- maybe a compiler bug? J |
|
From: Philippe W. <phi...@sk...> - 2012-06-25 22:34:08
|
On Mon, 2012-06-25 at 11:06 +0200, Julian Seward wrote: > On Saturday, June 23, 2012, Philippe Waroquiers wrote: > > On Sat, 2012-06-23 at 09:17 +0200, Julian Seward wrote: > > > This seems like is related to r12648. Not sure what the background > > > to that change is though. I will spark up my mac box and have a look. > > > I thought I had all this alignment stuff figured out already. > > > > The same assert was already failing before (e.g. > > the tests of r12595, 30 may). > > > > It looks like r12648 is a trial by Bart to fix this assert, but it > > did not persuade the compiler and/or the linker to do the required > > alignment. > > I tried to reproduced the failure, both with and without the r12648 change, > but failed. This is on Macos 10.7.3 (Lion, recently updated) with the > default XCode, on a non-AVX-capable CPU. So I am not sure what is going > on -- maybe a compiler bug? Might be a compiler or linker bug. In the Valgrind code, I do not see what more to do than the alignment attribute that Bart added. So, I am afraid that someone having an access to a Macos 10.8.0 will have to dig deeper into that problem. Philippe |
|
From: Rich C. <rc...@wi...> - 2012-06-30 12:45:19
|
I enabled the printf near the assert to see the values. > gst 0x3895DF70 352, sh1 0x3895E0D0 352, sh2 0x3895E230 352, spill 0x3895E390 4096 I'll keep digging. Rich On Tue, 26 Jun 2012 00:34:07 +0200 Philippe Waroquiers <phi...@sk...> wrote: > On Mon, 2012-06-25 at 11:06 +0200, Julian Seward wrote: > > On Saturday, June 23, 2012, Philippe Waroquiers wrote: > > > On Sat, 2012-06-23 at 09:17 +0200, Julian Seward wrote: > > > > This seems like is related to r12648. Not sure what the background > > > > to that change is though. I will spark up my mac box and have a look. > > > > I thought I had all this alignment stuff figured out already. > > > > > > The same assert was already failing before (e.g. > > > the tests of r12595, 30 may). > > > > > > It looks like r12648 is a trial by Bart to fix this assert, but it > > > did not persuade the compiler and/or the linker to do the required > > > alignment. > > > > I tried to reproduced the failure, both with and without the r12648 change, > > but failed. This is on Macos 10.7.3 (Lion, recently updated) with the > > default XCode, on a non-AVX-capable CPU. So I am not sure what is going > > on -- maybe a compiler bug? > Might be a compiler or linker bug. In the Valgrind code, I do not see > what more to do than the alignment attribute that Bart added. > > So, I am afraid that someone having an access to a Macos 10.8.0 will > have to dig deeper into that problem. > > Philippe > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers -- Rich Coe rc...@wi... |
|
From: Julian S. <js...@ac...> - 2012-06-30 14:38:48
|
On Saturday, June 30, 2012, Rich Coe wrote: > I enabled the printf near the assert to see the values. > > > gst 0x3895DF70 352, sh1 0x3895E0D0 352, sh2 0x3895E230 352, spill > > 0x3895E390 4096 > > I'll keep digging. I have the impression (although I could be wrong) that this is pretty simple. Basically the compiler has ignored repeated requests to 32-align VG_(threadstate) and the 3-per-thread VexGuestArchState structures, and has instead 16 aligned it. One thing you could try is to ask for the type U256 to be 32 aligned, although that might not be a good idea, and I don't think it will help. I increased the alignment requirement from 16 to 32 on doing AVX support recently. This was on the basis that the backend would generate 256-bit expressions into YMM registers, which then would be saved/reloaded from the guest state area using aligned memory operations. However, it turned out to be infeasible to generate 256 bit wide code, because AVX doesn't have enough 256-bit integer stuff to handle the Memcheck instrumentation of 256-bit AVX floating point insns. So I fell back to a Plan B of doing 256 bit code generation using pairs of 128 bit registers. Anyway, to cut a long story short, I thought the 32-alignment would be necessary but actually it isn't. So in the worst case we could back off to 16-alignment. However, I would prefer not to do that since there might come a day where 32-alignment is actually necessary. J |
|
From: Rich C. <rc...@wi...> - 2012-07-16 10:45:27
|
The address for _vgPlain_threads is 32-bit aligned in the produced .o/.a
nm coregrind/libcoregrind-amd64-darwin.a
0000000000376b80 C _vgPlain_threads
nm coregrind/libcoregrind-x86-darwin.a
0028c580 C _vgPlain_threads
However in the x86 binary for memcheck, the address is no longer 32-bit
aligned.
.in_place/memcheck-amd64-darwin.nm:0000000138edbec0 S _vgPlain_threads
.in_place/memcheck-x86-darwin.nm:3895da70 S _vgPlain_threads
It might be possible to specify a linker option to fix this.
Rich
On Sat, 30 Jun 2012 16:36:17 +0200
Julian Seward <js...@ac...> wrote:
> On Saturday, June 30, 2012, Rich Coe wrote:
> > I enabled the printf near the assert to see the values.
> >
> > > gst 0x3895DF70 352, sh1 0x3895E0D0 352, sh2 0x3895E230 352, spill
> > > 0x3895E390 4096
> >
> > I'll keep digging.
>
> I have the impression (although I could be wrong) that this is
> pretty simple. Basically the compiler has ignored repeated requests
> to 32-align VG_(threadstate) and the 3-per-thread VexGuestArchState
> structures, and has instead 16 aligned it.
>
> One thing you could try is to ask for the type U256 to be 32 aligned,
> although that might not be a good idea, and I don't think it will
> help.
>
> I increased the alignment requirement from 16 to 32 on doing AVX
> support recently. This was on the basis that the backend would
> generate 256-bit expressions into YMM registers, which then would
> be saved/reloaded from the guest state area using aligned memory
> operations. However, it turned out to be infeasible to generate
> 256 bit wide code, because AVX doesn't have enough 256-bit integer
> stuff to handle the Memcheck instrumentation of 256-bit AVX floating
> point insns. So I fell back to a Plan B of doing 256 bit code
> generation using pairs of 128 bit registers.
>
> Anyway, to cut a long story short, I thought the 32-alignment would be
> necessary but actually it isn't. So in the worst case we could back
> off to 16-alignment. However, I would prefer not to do that since
> there might come a day where 32-alignment is actually necessary.
>
> J
--
Rich Coe rc...@wi...
|
|
From: Rich C. <rc...@wi...> - 2012-07-16 11:04:15
|
For gcc on x86, -malign-double will do what is needed. According to the man page, this option is automatically enabled for x86-64. Rich On Sat, 30 Jun 2012 16:36:17 +0200 Julian Seward <js...@ac...> wrote: > On Saturday, June 30, 2012, Rich Coe wrote: > > I enabled the printf near the assert to see the values. > > > > > gst 0x3895DF70 352, sh1 0x3895E0D0 352, sh2 0x3895E230 352, spill > > > 0x3895E390 4096 > > > > I'll keep digging. > > I have the impression (although I could be wrong) that this is > pretty simple. Basically the compiler has ignored repeated requests > to 32-align VG_(threadstate) and the 3-per-thread VexGuestArchState > structures, and has instead 16 aligned it. > > One thing you could try is to ask for the type U256 to be 32 aligned, > although that might not be a good idea, and I don't think it will > help. > > I increased the alignment requirement from 16 to 32 on doing AVX > support recently. This was on the basis that the backend would > generate 256-bit expressions into YMM registers, which then would > be saved/reloaded from the guest state area using aligned memory > operations. However, it turned out to be infeasible to generate > 256 bit wide code, because AVX doesn't have enough 256-bit integer > stuff to handle the Memcheck instrumentation of 256-bit AVX floating > point insns. So I fell back to a Plan B of doing 256 bit code > generation using pairs of 128 bit registers. > > Anyway, to cut a long story short, I thought the 32-alignment would be > necessary but actually it isn't. So in the worst case we could back > off to 16-alignment. However, I would prefer not to do that since > there might come a day where 32-alignment is actually necessary. > > J -- Rich Coe rc...@wi... |
|
From: Julian S. <js...@ac...> - 2012-07-16 11:06:44
|
On Monday, July 16, 2012, Rich Coe wrote: > For gcc on x86, -malign-double will do what is needed. Can you clarify? What does the man page say about -malign-double? J |
|
From: Rich C. <rc...@wi...> - 2012-07-16 11:41:31
|
On Mon, 16 Jul 2012 13:03:25 +0200
Julian Seward <js...@ac...> wrote:
> On Monday, July 16, 2012, Rich Coe wrote:
> > For gcc on x86, -malign-double will do what is needed.
>
> Can you clarify? What does the man page say about -malign-double?
>
> J
> -malign-double
> -mno-align-double
> Control whether GCC aligns "double", "long double", and "long long"
> variables on a two word boundary or a one word boundary. Aligning
> "double" variables on a two word boundary will produce code that runs
> somewhat faster on a Pentium at the expense of more memory.
>
> On x86-64, -malign-double is enabled by default.
Then there's this. Not very desirable for V. bummer.
> Warning: if you use the -malign-double switch, structures containing
> the above types will be aligned differently than the published
> application binary interface specifications for the 386 and will not
> be binary compatible with structures in code compiled without
> that switch.
I'll keep looking.
rev 12742 broke the darwin build, this patch makes it build again.
Index: coregrind/m_debuginfo/readmacho.c
===================================================================
--- coregrind/m_debuginfo/readmacho.c (revision 12749)
+++ coregrind/m_debuginfo/readmacho.c (working copy)
@@ -1045,6 +1045,14 @@
Word debug_loc_sz;
UChar* debug_name_img;
Word debug_name_sz;
+ UChar* debug_str_alt_img = NULL; /* .debug_str (alternate) */
+ Word debug_str_alt_sz = 0;
+ UChar* debug_line_alt_img = NULL; /* .debug_str (alternate) */
+ Word debug_line_alt_sz = 0;
+ UChar* debug_info_alt_img = NULL; /* .debug_str (alternate) */
+ Word debug_info_alt_sz = 0;
+ UChar* debug_abbv_alt_img = NULL; /* .debug_str (alternate) */
+ Word debug_abbv_alt_sz = 0;
debug_info_img =
getsectdata(iid.macho_img, iid.macho_img_szB,
@@ -1087,7 +1095,8 @@
NULL, 0,
debug_abbv_img, debug_abbv_sz,
debug_line_img, debug_line_sz,
- debug_str_img, debug_str_sz );
+ debug_str_img, debug_str_sz,
+ debug_str_alt_img, debug_str_alt_sz);
/* The new reader: read the DIEs in .debug_info to acquire
information on variable types and locations. But only if
@@ -1102,7 +1111,11 @@
debug_line_img, debug_line_sz,
debug_str_img, debug_str_sz,
debug_ranges_img, debug_ranges_sz,
- debug_loc_img, debug_loc_sz
+ debug_loc_img, debug_loc_sz,
+ debug_info_alt_img, debug_info_alt_sz,
+ debug_abbv_alt_img, debug_abbv_alt_sz,
+ debug_line_alt_img, debug_line_alt_sz,
+ debug_str_alt_img, debug_str_alt_sz
);
}
}
--
Rich Coe rc...@wi...
|
|
From: Julian S. <js...@ac...> - 2012-07-17 08:02:27
|
On Monday, July 16, 2012, Rich Coe wrote: > > -malign-double > > -mno-align-double > > > > Control whether GCC aligns "double", "long double", and "long > > long" variables on a two word boundary or a one word boundary. > > Aligning "double" variables on a two word boundary will produce > > code that runs somewhat faster on a Pentium at the expense of > > more memory. I don't believe this will fix the problem. I suspect we're looking at a compiler or linker bug and the only option is to back off to 16 alignment, which as per my comments earlier in the thread, is still OK. J |
|
From: Julian S. <js...@ac...> - 2012-07-20 16:55:55
|
On Monday, July 16, 2012, Rich Coe wrote: Rich, which versions of XCode and MacOSX does this alignment failure happen on? I just tested with XCode 4.3 on OSX 10.7 using both gcc and clang (using the fix for #295427) and I can't get it to fail. It does however appear to fail with XCode-somewhat-ancient on OSX 10.6. J > On Mon, 16 Jul 2012 13:03:25 +0200 > > Julian Seward <js...@ac...> wrote: > > On Monday, July 16, 2012, Rich Coe wrote: > > > For gcc on x86, -malign-double will do what is needed. > > > > Can you clarify? What does the man page say about -malign-double? > > > > J > > > > -malign-double > > -mno-align-double > > > > Control whether GCC aligns "double", "long double", and "long > > long" variables on a two word boundary or a one word boundary. > > Aligning "double" variables on a two word boundary will produce > > code that runs somewhat faster on a Pentium at the expense of > > more memory. > > > > On x86-64, -malign-double is enabled by default. > > Then there's this. Not very desirable for V. bummer. > > > Warning: if you use the -malign-double switch, structures > > containing the above types will be aligned differently than the > > published application binary interface specifications for the 386 > > and will not be binary compatible with structures in code > > compiled without that switch. > > I'll keep looking. > > > rev 12742 broke the darwin build, this patch makes it build again. > > Index: coregrind/m_debuginfo/readmacho.c > =================================================================== > --- coregrind/m_debuginfo/readmacho.c (revision 12749) > +++ coregrind/m_debuginfo/readmacho.c (working copy) > @@ -1045,6 +1045,14 @@ > Word debug_loc_sz; > UChar* debug_name_img; > Word debug_name_sz; > + UChar* debug_str_alt_img = NULL; /* .debug_str (alternate) */ > + Word debug_str_alt_sz = 0; > + UChar* debug_line_alt_img = NULL; /* .debug_str (alternate) */ > + Word debug_line_alt_sz = 0; > + UChar* debug_info_alt_img = NULL; /* .debug_str (alternate) */ > + Word debug_info_alt_sz = 0; > + UChar* debug_abbv_alt_img = NULL; /* .debug_str (alternate) */ > + Word debug_abbv_alt_sz = 0; > > debug_info_img = > getsectdata(iid.macho_img, iid.macho_img_szB, > @@ -1087,7 +1095,8 @@ > NULL, 0, > debug_abbv_img, debug_abbv_sz, > debug_line_img, debug_line_sz, > - debug_str_img, debug_str_sz ); > + debug_str_img, debug_str_sz, > + debug_str_alt_img, debug_str_alt_sz); > > /* The new reader: read the DIEs in .debug_info to acquire > information on variable types and locations. But only if > @@ -1102,7 +1111,11 @@ > debug_line_img, debug_line_sz, > debug_str_img, debug_str_sz, > debug_ranges_img, debug_ranges_sz, > - debug_loc_img, debug_loc_sz > + debug_loc_img, debug_loc_sz, > + debug_info_alt_img, debug_info_alt_sz, > + debug_abbv_alt_img, debug_abbv_alt_sz, > + debug_line_alt_img, debug_line_alt_sz, > + debug_str_alt_img, debug_str_alt_sz > ); > } > } |
|
From: Rich C. <rc...@wi...> - 2012-07-21 04:51:49
|
I agree. I have MacOSX 10.6.8 running Xcode 3.2.6 (1761) The other mac died where I was planning to upgrade to Lion. I think it had a similar version. Rich On Fri, 20 Jul 2012 18:51:28 +0200 Julian Seward <js...@ac...> wrote: > On Monday, July 16, 2012, Rich Coe wrote: > > Rich, which versions of XCode and MacOSX does this alignment failure > happen on? I just tested with XCode 4.3 on OSX 10.7 using both gcc > and clang (using the fix for #295427) and I can't get it to fail. > > It does however appear to fail with XCode-somewhat-ancient on OSX 10.6. > > J > > > On Mon, 16 Jul 2012 13:03:25 +0200 > > > > Julian Seward <js...@ac...> wrote: > > > On Monday, July 16, 2012, Rich Coe wrote: > > > > For gcc on x86, -malign-double will do what is needed. > > > > > > Can you clarify? What does the man page say about -malign-double? > > > > > > J > > > > > > -malign-double > > > -mno-align-double > > > > > > Control whether GCC aligns "double", "long double", and "long > > > long" variables on a two word boundary or a one word boundary. > > > Aligning "double" variables on a two word boundary will produce > > > code that runs somewhat faster on a Pentium at the expense of > > > more memory. > > > > > > On x86-64, -malign-double is enabled by default. > > > > Then there's this. Not very desirable for V. bummer. > > > > > Warning: if you use the -malign-double switch, structures > > > containing the above types will be aligned differently than the > > > published application binary interface specifications for the 386 > > > and will not be binary compatible with structures in code > > > compiled without that switch. > > > > I'll keep looking. > > > > > > rev 12742 broke the darwin build, this patch makes it build again. > > > > Index: coregrind/m_debuginfo/readmacho.c > > =================================================================== > > --- coregrind/m_debuginfo/readmacho.c (revision 12749) > > +++ coregrind/m_debuginfo/readmacho.c (working copy) > > @@ -1045,6 +1045,14 @@ > > Word debug_loc_sz; > > UChar* debug_name_img; > > Word debug_name_sz; > > + UChar* debug_str_alt_img = NULL; /* .debug_str (alternate) */ > > + Word debug_str_alt_sz = 0; > > + UChar* debug_line_alt_img = NULL; /* .debug_str (alternate) */ > > + Word debug_line_alt_sz = 0; > > + UChar* debug_info_alt_img = NULL; /* .debug_str (alternate) */ > > + Word debug_info_alt_sz = 0; > > + UChar* debug_abbv_alt_img = NULL; /* .debug_str (alternate) */ > > + Word debug_abbv_alt_sz = 0; > > > > debug_info_img = > > getsectdata(iid.macho_img, iid.macho_img_szB, > > @@ -1087,7 +1095,8 @@ > > NULL, 0, > > debug_abbv_img, debug_abbv_sz, > > debug_line_img, debug_line_sz, > > - debug_str_img, debug_str_sz ); > > + debug_str_img, debug_str_sz, > > + debug_str_alt_img, debug_str_alt_sz); > > > > /* The new reader: read the DIEs in .debug_info to acquire > > information on variable types and locations. But only if > > @@ -1102,7 +1111,11 @@ > > debug_line_img, debug_line_sz, > > debug_str_img, debug_str_sz, > > debug_ranges_img, debug_ranges_sz, > > - debug_loc_img, debug_loc_sz > > + debug_loc_img, debug_loc_sz, > > + debug_info_alt_img, debug_info_alt_sz, > > + debug_abbv_alt_img, debug_abbv_alt_sz, > > + debug_line_alt_img, debug_line_alt_sz, > > + debug_str_alt_img, debug_str_alt_sz > > ); > > } > > } > -- Rich Coe rc...@wi... |