> We tried this here (upstream) with 2.2.1 on i686, and with latest CVS on > x86_64, > and we don't get the segfault but we do get:
interesting. but I use 32bit machine, you seem to use 64bit architecture, doesn't it imply 64bit pointers and/or different memory alignment? i.e. you just might be out of luck to trigger that fault :-) did you try running valgrind? e.g. valgrind dot -o/dev/null compressor.dot it should detect any memory mishandling. the valgrind.log says that the problem is somewhere with splines code in dynamic library: ==9257== Invalid read of size 4 ==9257== at 0x1BAFAFD5: (within /usr/lib/graphviz/libdotgen.so.0.0.0) ==9257== by 0x1BAFA775: dot_splines (in /usr/lib/graphviz/libdotgen.so.0.0.0) ==9257== by 0x1BAF2129: dot_layout (in /usr/lib/graphviz/libdotgen.so.0.0.0) ==9257== by 0x8048929: (within /usr/bin/dot) ==9257== by 0x1BB6096F: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.2.so) Such things should never appear in any useful software. If code included debug info you would get the source file and line number in this log, you'll love valgrind :-) > $ dot compressor.dot >/dev/null > Error: lost IUT_ActionHandler ENV_Action edge > Error: lost IUT_ActionHandler ENV_Action edge > Error: lost IUT_ActionHandler ENV_Action edge I also get these messages, not sure how to interpret them, seems that those edges are just lost (but why?). > So we're not completely innocent, but perhaps the segfault is debian > specific? could be. I am not debian-expert, I don't know how to rebuild the package with debug info efficiently, sorry. marius
