Source: pmw Version: 1:4.24-1 Severity: serious Justification: doing nonportable things with pointers can lead to data corruption
Hi, I’ve found out the reason for the FTBFS from: http://buildd.debian-ports.org/status/fetch.php?pkg=pmw&arch=m68k&ver=1%3A4.24-1&stamp=1356646278 Unfunnily, this smells evil: the following patch fixes it… --- /var/cache/pbuilder/build/cow.32073/tmp/buildd/pmw-4.24/src/ps.c~ 2012-12-28 03:16:27.390040000 +0000 +++ /var/cache/pbuilder/build/cow.32073/tmp/buildd/pmw-4.24/src/ps.c 2012-12-28 03:16:47.350040000 +0000 @@ -894,7 +894,7 @@ uschar s[10]; /* One-to-one mappings are represented by small integers */ -if ((long int)p < 256) +if ((unsigned long int)p < 256) { s[misc_ord2utf8((long int)p, s)] = 0; ps_basic_string(s, font_mf, pointsize, TRUE, x, y, 0); … but the build fails later on with… ../src/pmw -F ../fontmetrics -H ../PSheader -eps -nowidechars -o postscript/music53 examples/ex53 sdop -S . spec.xml GS_FONTPATH=/tmp/buildd/pmw-4.24/doc/../psfonts ps2pdf spec.ps spec.pdf Error: /syntaxerror in --%ztokenexec_continue-- Operand stack: ST Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1173/1684(ro)(G)-- --dict:0/20(G)-- --dict:182/200(L)-- Current allocation mode is local Last OS error: No such file or directory GPL Ghostscript 9.05: Unrecoverable error, exit code 1 GPL Ghostscript 9.05: ERROR: A pdfmark destination page 191 points beyond the last page 131. make[2]: *** [spec.pdf] Error 1 … which is probably just another manifestation of the same thing. A bit of explanation: p is a *pointer*, retrieved from a table whose C type is “array of pointer to struct mfstr”. Then, it’s cast to an *integral type* hoping it fits (usually the case in Debian) and checked if it’s a “small value”. However, gdb shows it’s not really small: (gdb) print p $4 = (mfstr *) 0x800465d0 Although, reinterpreting 0x800465d0 as (signed!) long int sure is smaller than 256, as it’s negative. This is a subtle bug, possibly leading to data corruption, and to add insult to injury, ASLR dependent. It may always fail or always pass on some architectures, and differ per run on others. Anyway, here's at least a patch for the first issue ;-) in case you really want to maintain this… bye, //mirabilos -- I want one of these. They cost 720 € though… good they don’t have the HD hole, which indicates 3½″ floppies with double capacity… still. A tad too much, atm. ‣ http://www.floppytable.com/floppytable-images-1.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
