I see a bug has been filed about this here:
http://bugs.kde.org/show_bug.cgi?id=268792
Now this is publicly released is there any workaround or possible fix?
--
Mike McQuaid
http://mikemcquaid.com
--
Enable your softwar
A memset immediately after the malloc but before the for loop should take care
of this problem. The for loop may execute before your other nested
initialization occurs.
memset(matrix, 0, (size * sizeof(in)));
Satya
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: Santo
Santosh,
Why not use calloc() instead of malloc()?
John
On 03/28/2011 07:08 PM, Santosh Navale wrote:
Hi Florian,
Thanks for the suggestion. As far as I know, this one of the ways of
declaring a 2D matrix in C. Please correct me if I am wrong. The
initialization happens in another nested fo
On Mon, Mar 28, 2011 at 11:14 PM, Julian Seward wrote:
> On Monday, March 28, 2011, Bart Van Assche wrote:
>> On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward wrote:
>> > On Monday, March 28, 2011, Piotr JaroszyĆski wrote:
>> > > I think the proper solution is to add __attribute__((unused)) to
>> >
Hi David,
That is correct. I am printing matrix[i][j] at line 42. But I am
initializing the matrix between the lines 28 and 42.
I figured out the problem with a little help from my friend. Turns out I was
improperly incrementing a variable that I was using to malloc other arrays.
But the strange
Hi Satya,
I have ensured that the initialization occurs before the data is
used/printed. So I believe memset is not required. I could give this a try
and see if it works. By the way, I figured out the error and it is a
improper incrementing of a variable.
Thanks
Santosh
On Tue, Mar 29, 2011 at
Am 26.03.2011 08:52, schrieb Julian Seward:
>
>> I get this behaviour on various distributions and several people
>> confirmed. I now wonder if there is a bug in udev or something is wrong
>> in valgrind? Any idea from the valgrind perspective?
>
> Yes: the program is buggy (reads freed memory) a
Can anyone offer any suggestions about how to use valgrind in an environment
which doesn't support shared libraries? I could staticly link the valgrind
components into my program but it isn't clear how to handle initialization,
startup, etc. The first problem will be the multiple main routines.
On 29/03/11 15:33, Jason Kraftcheck wrote:
> Can anyone offer any suggestions about how to use valgrind in an environment
> which doesn't support shared libraries? I could staticly link the valgrind
> components into my program but it isn't clear how to handle initialization,
> startup, etc. The
On 29/03/11 15:25, Stefan Kost wrote:
> Am 26.03.2011 08:52, schrieb Julian Seward:
>>
>>> I get this behaviour on various distributions and several people
>>> confirmed. I now wonder if there is a bug in udev or something is wrong
>>> in valgrind? Any idea from the valgrind perspective?
>>
>> Yes:
On 03/29/2011 10:13 AM, Tom Hughes wrote:
> On 29/03/11 15:33, Jason Kraftcheck wrote:
>
>> Can anyone offer any suggestions about how to use valgrind in an environment
>> which doesn't support shared libraries? I could staticly link the valgrind
>> components into my program but it isn't clear h
On 29/03/11 16:25, Jason Kraftcheck wrote:
> On 03/29/2011 10:13 AM, Tom Hughes wrote:
>> On 29/03/11 15:33, Jason Kraftcheck wrote:
>>
>>> Can anyone offer any suggestions about how to use valgrind in an environment
>>> which doesn't support shared libraries? I could staticly link the valgrind
>>
Hi,
*Environment: 32 bit Valgrind (3.4) on FreeBSD 6.x*
We have a requirement that the application we run uses a specific UID
which is different from the original application. When we run the
application with valgrind to detect memory leaks, the application runs
with the uid as that of the va
On 03/29/2011 10:50 AM, Tom Hughes wrote:
>
> Messages about starting the tool refer to the point at which the
> valgrind launcher execs the tool binary in the valgrind library directory.
>
> Specifically that error means that the call to execve that the launcher
> makes to switch to the tool bi
> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out
>
> Now I see the following error:
Try again with
VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux \
-d -d -v -v a.out
so at least we can see what's going on at startup. There may
be a lot of output.
J
-
On 03/29/2011 11:21 AM, Julian Seward wrote:
>
>> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out
>>
>> Now I see the following error:
>
> Try again with
>
> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux \
> -d -d -v -v a.out
>
> so at least we can see what'
You might need to link the app with a non standard load address,
in the same way that the valgrind executables are normally
linked. See coregrind/link_tool_exe_linux.in for background.
In short (I think) you need to get -Ttext=0x3800 to the linker.
Once done, you should have an entry point
On 03/29/2011 01:59 PM, Julian Seward wrote:
>
> You might need to link the app with a non standard load address,
> in the same way that the valgrind executables are normally
> linked. See coregrind/link_tool_exe_linux.in for background.
>
> In short (I think) you need to get -Ttext=0x3800 t
Hi,
I'm trying to debug an app on Ubuntu 10.10 x86_64. When I open it in
exp-ptrcheck, I get the following error:
sysno == 290
exp-ptrcheck: the 'impossible' happened:
unhandled syscall
==8235==at 0x3801303F: report_and_quit (m_libcassert.c:191)
==8235==by 0x38013138: panic (m_
> I'm trying to debug an app on Ubuntu 10.10 x86_64. When I open it in
> exp-ptrcheck, I get the following error:
>
> sysno == 290
> exp-ptrcheck: the 'impossible' happened:
> unhandled syscall
-/usr/include/asm/unistd_64.h
#define __NR_eventfd2 290
-
> Thanks for the reply. ... I'm not sure what 2.6.22-rc1 has to do with this
> syscall? Or what, if anything, I can do?
The eventfd2 syscall was added to the Linux kernel in mid 2007, for Linux
2.6.22,
but exp-ptrcheck has no handler for it today. Section 11.6, Limitations, of the
valgrind man
On Mar 29, 2011, at 11:11 PM, John Reiser wrote:
>> Thanks for the reply. ... I'm not sure what 2.6.22-rc1 has to do with this
>> syscall? Or what, if anything, I can do?
>
> The eventfd2 syscall was added to the Linux kernel in mid 2007, for Linux
> 26.22,
> but exp-ptrcheck has no handler f
22 matches
Mail list logo