Building the hardy package on hardy with dpkg-buildpackage also results in a binary that gives the stack-smashing error (though the hardy binary package worked fine).
Building with -fno-stack-protector as part of CFLAGS makes it ignore the stack smashing, and the program works again. My guess (I don't know how to check this) is that the default setting for -fno-stack-protector changed on the machines used to produce jaunty binary packages, relative to the machines used for intrepid packages (but that it didn't change on hardy or intrepid themselves). But I've found the cause of the problem. gmemusage assumes that the names read from /proc/*/status can fit in 14 characters (including the null), but some of them are actually 15 characters (so 16 with the null). I'm attaching a patch. I've separated the number out into a #define in case it changes again. Is this size documented anywhere, or set in any system include file? As long as I was making a patch I also fixed a couple of warnings and some unsafe behavior (changed strcpy to strncpy). ** Attachment added: "Fix the stack smashing, plus a couple of other items" http://launchpadlibrarian.net/28828334/stacksmash.diff -- terminated on stack smashing detected message https://bugs.launchpad.net/bugs/370735 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
