On Mon, Dec 10, 2012 at 12:35 PM, Mark Atkinson <atkin901_at_gmail.com> wrote: > vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 > ==33074== valgrind: Unrecognised instruction at address 0x380434e9. > ==33074== at 0x380434E9: ??? (in > /usr/local/lib/valgrind/memcheck-x86-freebsd) > ==33074== by 0x323C48: qt_safe_select(int, fd_set*, fd_set*, > fd_set*, timeval const*) (qcore_unix.cpp:83) > ==33074== by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int) > (qprocess_unix.cpp:998) > ==33074== by 0x28021D: QProcessPrivate::waitForStarted(int) > (qprocess_unix.cpp:1031) > ==33074== by 0x1FFA02: QProcess::waitForStarted(int) > (qprocess.cpp:1687) > ==33074== by 0x1FEAEA: QProcess::waitForFinished(int) > (qprocess.cpp:1752) > ==33074== by 0x805487A: AutoMoc::echoColor(QString const&) > (kde4automoc.cpp:74) > ==33074== by 0x805264F: AutoMoc::generateMoc(QString const&, > QString const&) (kde4automoc.cpp:569) > ==33074== by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470) > ==33074== by 0x804AAEE: main (kde4automoc.cpp:114) > > Full valgrind output is at http://pastebin.com/KQTKYGX5 > This sounds like a valgrind bug I reported related to sigreturn: https://bitbucket.org/stass/valgrind-freebsd/issue/4/crash-in-x86_freebsd_subst_for_sigreturn Unfortunately I don't understand the mechanics of signal handling well enough to take this to completion.Received on Mon Dec 10 2012 - 21:06:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC