Frederik Deweerdt writes: > From the program's point of view, all memory space is his, some > addresses are allocated, some not. But all the memory (eg. from 0 to > 0xffffffff on a 32bits arch) is potentially his.
Ok, so what I understand here is that you confirm that the program won't segfault as long as I am not accessing another program's allocated memory, even if I get out my own allocated memory. Is that so? >> >> I am trying to understand such a violation in the utf-8 branch, I found the >> line where it segfaults with valgring/gdb, but don't manage to find why the >> pointer was not allocated (my first verification seem to conclude it should >> be allocated), and why it does not always segfault to the same line/column >> for the exact same action. > Care to send valgrind's trace? Yes I can and I will as soon as I have some time (right now, I cannot). Several memory loss are seen in Valgrind, and I could fix some of them (4 exactly, which were already existing before my branch I think). But for many of those I have looked at, I wonder whether they are not outside the program, in the used library (so we cannot do much). > You could have a look at gdb's watch. Ok thanks for the hint. It seems what I was looking for. I should have read better the doc. I will look all what I can do with this... Jehan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Materm-devel mailing list Materm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/materm-devel mrxvt home page: http://materm.sourceforge.net
