On 01/02/2015 10:13 AM, Philippe Waroquiers wrote:
> You can try with
> valgrind --tool=exp-sgcheck
> (sg = stack and global).
> This is an experimental tool, so not as polished as the others
> (e.g. might have a lot of false positive).
> But it detects (some of) the problems with stack and glo
On 02/01/15 19:15, "João M. S. Silva" wrote:
> Spoke too early. Sorry for the noise.
>
> -fsanitize=address does not seem to work on armv7l, it seems to crash on
> runtime (I thought it worked on compile-time only):
>
> ==1280== ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0xbe99efb0
Spoke too early. Sorry for the noise.
-fsanitize=address does not seem to work on armv7l, it seems to crash on
runtime (I thought it worked on compile-time only):
==1280== ERROR: AddressSanitizer: stack-buffer-overflow on address
0xbe99efb0 at pc 0x29483 bp 0xbe99ef38 sp 0xbe99ef3c
WRITE of siz
On 01/02/2015 07:04 AM, Tom Hughes wrote:
> Try building with -fsanitize=address which is a clang/gcc tool that does
> similar things to valgrind, but because it works at compile time it can
> insert gaps between stack variables.
Thanks, I've added that switch to my list. It seems to work both on
On Fri, 2015-01-02 at 00:44 +, "João M. S. Silva" wrote:
> On 01/02/2015 12:05 AM, Tom Hughes wrote:
> > No. Stack overruns are not detected because there is no guard space
> > between stack variables like there is between heap variables.
>
> OK, I didn't know that. Now I'm a bit worried :P I
On 02/01/15 00:44, "João M. S. Silva" wrote:
> Is there a way to check for stack memory errors? If it was not for the
> %s in the command string it could be caught with cppcheck, but with the
> %s only a runtime check would do, I guess.
Try building with -fsanitize=address which is a clang/gcc to
2015-01-02 2:21 GMT+01:00 John Reiser :
>
> If there is any doubt [you have at least 1% doubt] then you should replace
> all uses
> of sprintf with snprintf instead. Using snprintf is not a fool-proof
> cure-all.
> If the length limit is reached then the result has no terminating '\0',
> so subse
On 01/02/2015 01:21 AM, John Reiser wrote:
> If there is any doubt [you have at least 1% doubt] then you should replace
> all uses
> of sprintf with snprintf instead. Using snprintf is not a fool-proof
> cure-all.
> If the length limit is reached then the result has no terminating '\0',
> so sub
On 01/01/2015 04:44 PM, "João M. S. Silva" wrote:
> On 01/02/2015 12:05 AM, Tom Hughes wrote:
>> No. Stack overruns are not detected because there is no guard space
>> between stack variables like there is between heap variables.
>
> OK, I didn't know that. Now I'm a bit worried :P I thought my cod
On 01/02/2015 12:05 AM, Tom Hughes wrote:
> No. Stack overruns are not detected because there is no guard space
> between stack variables like there is between heap variables.
OK, I didn't know that. Now I'm a bit worried :P I thought my code was
99% clean :)
Is there a way to check for stack me
> Tom Hughes' suggestion to fix the invalid file descriptor first is
> valid. A memory overwrite can cause all kinds of problems (what if you
> overwrote 1 million characters of the buffer?) and many of the results
> afterward will be unreliable. Your program may appear to run correctly
> once, b
On 1/1/2015 3:16 PM, "João M. S. Silva" wrote:
> The problem is in:
>
> char command[128];
> sprintf(command, "first part of command %s second part of command",
> filename.c_str());
>
> The string is larger than 128 bytes. But valgrind does not detect this?
> Am I missing something?
>
> I forgot to
On 01/01/15 23:16, "João M. S. Silva" wrote:
> The problem is in:
>
> char command[128];
> sprintf(command, "first part of command %s second part of command",
> filename.c_str());
>
> The string is larger than 128 bytes. But valgrind does not detect this?
> Am I missing something?
No. Stack overru
The problem is in:
char command[128];
sprintf(command, "first part of command %s second part of command",
filename.c_str());
The string is larger than 128 bytes. But valgrind does not detect this?
Am I missing something?
I forgot to mention, I'm using valgrind from SVN in an ARM machine.
I us
Let me correct myself: gdb catches the change on fd, but I thought it
didn't because it didn't break the execution. It just got running 100%
CPU and when I pressed ctrl-c it stopped in the culprit line. It always
stopped on the same line which was strange but I didn't realize it was
the line wh
I moved the member variable from private to public because I thought gdb
needed it to be public in order to watch it. That's why I found out that
simply making it public would make the issue disappear.
Now I tried watching it with gdb without making it public: it still gets
damaged, but gdb doe
Using gdb you can put a watch on a variable or memory location. As soon as
it changes the program will break and you can look at what the last
instruction was. It probably won't seem to have anything to do with the fd
itself, probably an array or something that's getting overwritten.
I'd link to th
On 01/01/2015 06:03 PM, Tom Hughes wrote:
> Surely the easy fix is to fix your program to stop it trying to read
> from an invalid file descriptor? Surely that is a bug that you will want
> to fix anyway?
Yes. I've printed the fd value and it goes from 13 to 29541 with no
deliberate function over
On 01/01/15 17:52, "João M. S. Silva" wrote:
> I've searched in the documentation, Internet and mailing list archive,
> but could not find a way to address the following issue:
>
> How can I suppress the repetition of warnings, e.g.:
>
> ==1830== Warning: invalid file descriptor 29541 in syscall r
Hi,
I've searched in the documentation, Internet and mailing list archive,
but could not find a way to address the following issue:
How can I suppress the repetition of warnings, e.g.:
==1830== Warning: invalid file descriptor 29541 in syscall read()
which in my case appears thousands of times
20 matches
Mail list logo
