Hi Dave, I got attached bug report. It seems there is a bigger problem with the handling of images, since the test case, pict.rtf, also does not produce any image in the working directory. At least, the test case does not get unrtf to produce output garbage as demonstrated in this bug report.
Additionally, there is a memory handling problem: % valgrind unrtf FUNDS\ RELEASE\ FORM..rtf > /tmp/output ==19089== Memcheck, a memory error detector ==19089== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19089== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19089== Command: unrtf FUNDS\ RELEASE\ FORM..rtf ==19089== ==19089== Invalid read of size 4 ==19089== at 0x401C2C: ??? (in /usr/bin/unrtf) ==19089== by 0x40750D: ??? (in /usr/bin/unrtf) ==19089== by 0x408041: ??? (in /usr/bin/unrtf) ==19089== by 0x4017CD: ??? (in /usr/bin/unrtf) ==19089== by 0x4E54B44: (below main) (libc-start.c:287) ==19089== Address 0x5bef5a0 is 90,000 bytes inside a block of size 90,016 free'd ==19089== at 0x4C29730: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19089== by 0x4074D1: ??? (in /usr/bin/unrtf) ==19089== by 0x408041: ??? (in /usr/bin/unrtf) ==19089== by 0x4017CD: ??? (in /usr/bin/unrtf) ==19089== by 0x4E54B44: (below main) (libc-start.c:287) ==19089== ==19089== ==19089== HEAP SUMMARY: ==19089== in use at exit: 2,488,733 bytes in 3,274 blocks ==19089== total heap usage: 19,992 allocs, 16,718 frees, 29,549,989 bytes allocated ==19089== ==19089== LEAK SUMMARY: ==19089== definitely lost: 5,972 bytes in 596 blocks ==19089== indirectly lost: 0 bytes in 0 blocks ==19089== possibly lost: 0 bytes in 0 blocks ==19089== still reachable: 2,482,761 bytes in 2,678 blocks ==19089== suppressed: 0 bytes in 0 blocks ==19089== Rerun with --leak-check=full to see details of leaked memory ==19089== ==19089== For counts of detected and suppressed errors, rerun with: -v thanks Willi PS: Did you get my previously forwarded bug reports? I haven't received an answer. -------- Original-Nachricht -------- Betreff: Bug#745195: unrtf 0.21 outputs hex.junk to stdout Weitersenden-Datum: Fri, 18 Apr 2014 19:00:02 +0000 Weitersenden-Von: Matus UHLAR - fantomas <uh...@fantomas.sk> Weitersenden-An: debian-bugs-dist@lists.debian.org Weitersenden-CC: Willi Mann <wi...@debian.org> Datum: Fri, 18 Apr 2014 20:48:51 +0200 Von: Matus UHLAR - fantomas <uh...@fantomas.sk> Antwort an: Matus UHLAR - fantomas <uh...@fantomas.sk>, 745...@bugs.debian.org An: sub...@bugs.debian.org Package: unrtf Version: 0.21.5-1 when converting RTF file with images attached to text, unrtf 0.21.5 outputs huge amount of text (looks like image data in hex) to output, where unrtf 0.19.2 present in wheezy shows at the same place something like: ### picture data found, WMF type is MM_ANISOTROPIC, picture dimensions are 7842 by 2125, depth 1 you can see the example RTF file and output from both unrtf versions on: http://test.fantomas.sk/unrtf/ -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
