the attached patch show how it crashes
if both #store has a #for with same dimensions it doesn't crash, but when dimensions are different, here come the bug
----- "Mathieu Bouchard" matju@artengine.ca a écrit :
On Thu, 17 Feb 2011, patko wrote:
the crash seems to come from this object: #X obj 80 277 #store here is the gdb message Program received signal SIGSEGV, Segmentation fault. 0x68738763 in probe () at
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_tree.h:462
462 { return
static_cast<_Link_type>(this->_M_impl._M_header._M_parent
gdb doesn't talk a lot, I hope it could be some help.
STL crashes are usually caused by a bug somewhere else, that corrupts
STL's private data, most often trees. I've seen that before, and if you don't have Valgrind, you're quite doomed.
Do you know any software that could help you debug ?
Another approach is to cut elements of the patch while making sure that it still crashes. Then we will know the bug to be in a smaller subset of
GridFlow's code.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC