Created attachment 52080 [details] WinWord6 file When I try to open the attached file... In LibreOffice 3.3 I have to choose the import filter. When I choose Microsoft Word 6, it says "This is not a WinWord6 file". In LibreOffice 3.4.3 and in master, it says immediately: "This is not a WinWord97 file". The file can be opened in MS Word 2003 without problems.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This is a Writer issue, therefore changed 'Component' field accordingly.
Still [REPRODUCIBLE] with LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b8), German langpack installed, on MacOS X 10.6.8 German. If I try to open the file, LibreOffice still just says "This is not a WinWord97 file". Changing Status to 'NEW'.
Created attachment 67215 [details] typescript with backtrace full from display of the msgbox I still see the error message with master 741c56a, pulled 2012-09-13 and configured with --enable-symbols --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-system-postgresql --enable-debug --enable-werror Terry.
It seems that the problem could be located in sw/source/filter/ww8/ww8toolbar.cxx:846 (function Tcg255::processSubStruct) When the file is loaded, LO enters in this function first time with parameter nId = 1, then goes to the switch: 849 case 0x1: 850 { 851 pSubStruct = new PlfMcd( false ); // don't read the id 852 break; 853 } Notice the comment 'don't read the id' whereas some lines after the switch, we have: 884 pSubStruct->ch = nId; 885 if ( !pSubStruct->Read( rS ) ) 886 return false; Since we don't return from this function like in "default" case, it fails at pSubStruct->Read, see: 885 if ( !pSubStruct->Read( rS ) ) (gdb) s PlfMcd::Read (this=0x5d3d870, rS=...) at /home/julien/compile-libreoffice/libo/sw/source/filter/ww8/ww8toolbar.cxx:970 970 OSL_TRACE("PffMcd::Read() stream pos 0x%x", rS.Tell() ); (gdb) n [Thread 0x7f995d8b2700 (LWP 23551) exited] 971 nOffSet = rS.Tell(); (gdb) n 972 Tcg255SubStruct::Read( rS ); (gdb) n 973 rS >> iMac; (gdb) n 974 if ( iMac ) (gdb) p iMac $30 = -430637046 (gdb) n 976 rgmcd = new MCD[ iMac ]; (gdb) p iMac $31 = -430637046 (gdb) n So I dynamically change nId value in order to go in "default" case and was able to open the file. So, perhaps an easy fix could be to add a "return false" in case 1 instead of break. Of course it's only a guess instead of a real understanding :-( Stephan/Caolán/Cedric: would one of you have some time to take a look to this?
assuming that's the problem my instincts would be to simply not parse that blob in the WW6 case seeing as its probably not exactly the same format as the WW8 case. caolanm->noelp: Do you have any examples of a ww8 .doc file which has a custom toolbar which should work for comparison purposes ? (and how do I see where does the custom toolbar stuff ends up ?)
(In reply to comment #6) > assuming that's the problem my instincts would be to simply not parse that > blob in the WW6 case seeing as its probably not exactly the same format as > the WW8 case. yup would be the first step I would take ( not sure about detecting the non-ww8 format but presumably done elsewhere ) > > caolanm->noelp: Do you have any examples of a ww8 .doc file which has a > custom toolbar which should work for comparison purposes ? (and how do I see > where does the custom toolbar stuff ends up ?) yeah, sent you privately an example ( sorry not to attach it here but it is from a customer document ) I guess it's possibly to create own custom toolbar stuff in a document ( but it's so long since I looked at that stuff I can't even recall how to do it )
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b2be75d95899a3babc16b2a590f8568cfca8124f Resolves: fdo#41554 ww6 file cannot be opened The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #8) > Caolan McNamara committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=b2be75d95899a3babc16b2a590f8568cfca8124f > > Resolves: fdo#41554 ww6 file cannot be opened > thanks, I was going to look at it today but you beat me to it. I wouldn't have spotted the need for the additional clean up, or was there some extra coring or something that triggered that? In any case... gratitude !!