The crash is forced by elecrric-fence, presumably as a way to get a back-trace when running inside a debugger.
valgrind on its own does not complain about anything related (mostly just unitialised bytes in various X11 writes). valgrind with electric-fence doesn't work, as valgrind hasn't been compiled with large enough VG_N_SEGMENTS. I believe this is because electric-fence is making more virtual memory pages than a program would normally use, as it wants to setup hardware catch areas for invalid reads / writes. I guess its possible that the electric-fence output is a red-herring, or is confused by the g_slice allocator. What makes me wounder though, is once I've hacked around the initial problems in gschem, and the back- trace shown (commented out some code which draws a toolbar), I can get it running to the point I wanted to debug anyway. I know I've seen gschem crash when manipulating a particular dialog, but its VERY difficult to repeat, and valgrind doesn't pick anything untoward up. electric-fence crashes the moment I hit the UI button I suspected was triggering some problems. -- gtk memory corruption found with electric-fence https://bugs.launchpad.net/bugs/131740 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
