On Thu, 2014-12-11 at 14:48 +0300, Mikhail Baikov wrote:
> On 12/05/2014 09:26 PM, Philippe Waroquiers wrote:
> > On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:
> >
> >> And the crash... I'm sorry it's not a segfault. It's a crash.
> >> One of the strange things is that inspite of --run-l
On 12/05/2014 09:26 PM, Philippe Waroquiers wrote:
> On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:
>
>> And the crash... I'm sorry it's not a segfault. It's a crash.
>> One of the strange things is that inspite of --run-libc-freeres set no
>> in the log appears
>> /bin/sh: symbol '__lib
On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:
> And the crash... I'm sorry it's not a segfault. It's a crash.
> One of the strange things is that inspite of --run-libc-freeres set no
> in the log appears
> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest...
This is I
On 12/04/2014 12:44 AM, Philippe Waroquiers wrote:
> Then I might have missed something in the mail exchanges.
>
> Your initial mail said that the bug is valgrind fails to find
> problems even in simple applications.
> The example shown was with /bin/true. This was reporting 'invalid read
> errors
On Wed, 2014-12-03 at 19:51 +0300, Mikhail Baikov wrote:
>
> The main problem for me is not in basic applications. The problem is
> that the application that I want to test works fine without valgrind but
> segfaults when I try to run it in valgrind.
>
Then I might have missed something in the
> On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote:
>
>> ==1654== Invalid read of size 4
>> ==1654==at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
>> ==1654== Address 0xbdd74b44 is on thread 1's stack
>> ==1654== 20 bytes below stack pointer
>> ==1654==
>> I also have
>>
On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote:
> ==1654== Invalid read of size 4
> ==1654==at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
> ==1654== Address 0xbdd74b44 is on thread 1's stack
> ==1654== 20 bytes below stack pointer
> ==1654==
> I also have
> # valgrind