> > I have 2 different boards running QNX 6.5 and mounting the exact same file
> > system.
> > One board is based on an NXP iMX53 SoC and the other one on a Texas
> > Instrument AM3352.
> > Since both SoC share the same instruction set (Cortex A8 - amv7le), they
> > can run the same binaries.
>
I have 2 different boards running QNX 6.5 and mounting the exact same file
system.
One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument
AM3352.
Since both SoC share the same instruction set (Cortex A8 - amv7le), they can
run the same binaries.
However, whereas Valgrin
> > Hi Valgrind community,
> >
> > I have 2 different boards running QNX 6.5 and mounting the exact same file
> > system.
> > One board is based on an NXP iMX53 SoC and the other one on a Texas
> > Instrument AM3352.
> > Since both SoC share the same instruction set (Cortex A8 - amv7le), they
>
On 2022-07-11 09:43, Cédric Perles wrote:
Hi Valgrind community,
I have 2 different boards running QNX 6.5 and mounting the exact same file
system.
One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument
AM3352.
Since both SoC share the same instruction set (Cortex A8
Hi Valgrind community,
I have 2 different boards running QNX 6.5 and mounting the exact same file
system.
One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument
AM3352.
Since both SoC share the same instruction set (Cortex A8 - amv7le), they can
run the same binaries.
H
Hi Philippe,
> Also, have you upgraded to 3.12, as suggested by John ?
Yes,I updated to 3.12 - could not see any difference to 3.11.
> Also, try with --read-inline-info=no
All the tests I did now (and the backtraces below) are done with this option
now -- does not seem to make any difference.
On Wed, 2017-01-04 at 13:43 +0100, frank_w...@web.de wrote:
> Happy new year!
>
>
> Am 08.12.2016 14:34 schrieb John Reiser:
> > [...]
> > Most of the time? Then run valgrind under gdb, get the traceback
> > at the time of the SIGSEGV, and file a bug report against valgrind.
> > $ gdb valgri
Happy new year!
Am 08.12.2016 14:34 schrieb John Reiser:
> [...]
> Most of the time? Then run valgrind under gdb, get the traceback
> at the time of the SIGSEGV, and file a bug report against valgrind.
> $ gdb valgrind
> (gdb) run --tool=memcheck /path/to/the/smallest/program/which/fails
> Most of the time, when I start valgrind like this:
> # valgrind --tool=memcheck
> it exits with a segmentation fault. I tried different programs, small and
> big, but this does not really seem to make a difference. ...
Most of the time? Then run valgrind under gdb, get the traceback
at the
Hi,
I have an embedded linux system similar to the BeagleBone. It runs buildroot on
it.
# uname -a
Linux xenon 4.4.21 #1 PREEMPT Thu Dec 8 12:19:53 CET 2016 armv7l GNU/Linux
Within the last days, I enabled valgrind in buildroot (version 3.11.0) to
examine memory issues in some programs.
> OS: Redhat 7.1 with gcc-3.0, binutils-2.18.
> This is with valgrind-3.6.1. valgrind 3.2.1 runs fine on same machine
> using same toolchain. FYI I was running valgrind with 'ls'.
> A plain valgrind without any progs actually shows segmentation fault.
Run "strace valgrind" and look near the end
> valgrind: the 'impossible' happened:
>Killed by fatal signal
> ==31001==at 0x38066A08: ??? (in
> /home/elem/local/lib/valgrind/none-x86-linux)
> ==31001==by 0x38066B2B: report_and_quit (m_libcassert.c:225)
> ==31001==by 0x38066CB5: panic (m_libcassert.c:277)
<>
You've probabl
valgrind: the 'impossible' happened:
Killed by fatal signal
==31001== at 0x38066A08: ??? (in
/home/elem/local/lib/valgrind/none-x86-linux)
==31001== by 0x38066B2B: report_and_quit (m_libcassert.c:225)
==31001== by 0x38066CB5: panic (m_libcassert.c:277)
==31001== by 0x38066CD9: vgPla
13 matches
Mail list logo
