Your message dated Sat, 05 Jul 2014 13:50:57 +0200 with message-id <[email protected]> has caused the report #745195, regarding unrtf 0.21 outputs hex.junk to stdout to be marked as having been forwarded to the upstream software author(s) [email protected]
(NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 745195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745195 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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 <[email protected]> Weitersenden-An: [email protected] Weitersenden-CC: Willi Mann <[email protected]> Datum: Fri, 18 Apr 2014 20:48:51 +0200 Von: Matus UHLAR - fantomas <[email protected]> Antwort an: Matus UHLAR - fantomas <[email protected]>, [email protected] An: [email protected] 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, [email protected] ; 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.
--- End Message ---
