On 18-08-12 02:39, mathog wrote:
On 17-Aug-2012 17:01, mathog wrote:
One of my patches causes the windows version to blow up reliably on save to EMF if and only if it sees a string consisting only of all characters above 127 (that is, all UTF-8 characters need at least one more character).
Strangely, the "fix" seems to have been logging out and back in again. The same code (not even a recompile) magically started working with the heap problem eliminated. Hopefully whatever gremlin this was has been permanently cast out of the system!
That said, I would still like to know if there is a way to trace the heap.
Assuming you loaded the symbols from inkscape.dbg, and that your stack is indeed corrupted, then there is very little you can do about it. My favourite tool for debugging this kind of thing is printf (frankly, I use it for almost all debugging).
You usually have at least some idea of where it's going wrong, so there you insert some printf statements and see which ones do get printed and which ones don't (be sure to end them with newline's btw., usually print statements are buffered per line). Then you gradually remove and add printf statements to get closer and closer to where the problem is. Once you begin having some idea of where it might go wrong you start printing values, etc....
A similar tactic can be accomplished (in some cases more easily) using a debugger by setting a breakpoint at some point before it crashes, and then stepping through the code. If this works and you're using a nice debugger, then this is probably more convenient than the above.
BTW, I seem to remember that valgrind can detect stack corruption, but I don't think it works on Windows (there is a Valgrind for Windows project, but it's pre-alpha).